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ABSTRACT 

This  Paper  presents  preliminary  guidelines  intended  to  serve  as  input  to  a  planned  DoD  Handbook  for  the 
Acquisition  and  Deployment  of  DoD  IETMs  with  the  specific  purpose  of  assuring  interoperability  of 
IETMs  among  various  end-users.  This  work  results  from  a  study  sponsored  jointly  by  the  Logistics 
Reinvention  Office  of  the  Office  of  the  Deputy  Under-Secretary  of  Defense  for  Logistics  (DUSD(L)/LRO), 
the  Joint  Electronic  Commerce  Project  Office  (JECPO),  and  the  Joint  [Logistics]  Commanders  Group  for 
Communication  and  Electronics  (JCG-CE).  The  resulting  Joint  IETM  Architecture  (JIA)  is  an  adaptive 
World-Wide-Web-Based  Architecture  for  the  deployment  of  DoD  Interactive  Electronic  Technical 
Manuals  (IETMs)  based  on  the  existing  technology,  industry  standards,  and  commercial  software  products 
being  developed  for  the  World  Wide  Web.  The  version  of  the  JIA  described  in  this  Report  is  for 
informational  purposes  in  order  to  provide  a  preliminary  overview  to  the  DoD  IETM  community  of  the 
overall  contents  of  a  planned  DoD  Handbook. 

The  objective  of  the  DoD  effort  to  develop  these  guidelines  has  been  to  create  an  IETM  architectural 
framework  that  fosters  acquisition-management  policies  and  procedures  that  will  guide  and  standardize 
IETM  acquisition,  management,  deployment,  and  display.  The  purpose  of  this  study  and  the  resultant  Joint 
IETM  Architecture  (JIA)  is  achievement  of  a  state  of  universal  end-user  interoperability  that: 

•  will  enable  maximum  interoperability  of  Technical  Information  accessed  and  displayed  by  a  user 
so  as  to  meet  the  needs  of  the  Defense  Logistics  community  in  supporting  the  material  readiness 
of  the  DoD  forces; 

•  will  serve  as  the  basis  for  a  formal  DoD-wide  adoption  of  the  proposed  approach  in  promulgating 
the  required  acquisition  and  field-support  policy. 

The  policy  recommendations  stemming  from  this  study  are  based  on  a  series  of  pilot-demonstration 
programs  carried  out  in  FY99  that  have  shown  the  applicability  and  efficacy  of  the  Architecture  in 
achieving  required  quality  and  interoperability  for  IETMs  which  support  a  broad  spectrum  of  candidate 
weapon  systems  of  the  Military  Services. 

The  set  of  guidelines  presented  in  this  Report  summarizes  the  recommended  Web-based  functional 
requirements  for  the  following  technical  areas: 

•  Object  Encapsulation  and  Component  Interface. 

•  Intranet  Server  and  Database  Interface. 

•  Common  Browser. 

•  Electronic  Addressing,  and  Library  Model 

These  aspects  of  a  COTS-environment  changeover  from  current  IETM  acquisition  and  maintenance 
procedures  to  a  Web-based  interoperable  approach  are  defined  and  described. 
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PREFACE 


Guidelines  contained  in  this  Report  have  been  prepared  by  the  Project  Leader  of  the  Tri- 
Service  IETM  Technology  Working  Group  IETM  Interoperability  Team,  in  advance  of 
the  delivery  of  the  actual  Final  Draft  of  the  DoD  Joint  IETM  Architecture  Handbook 
scheduled  for  the  Fall  of  1999.  The  Report  is  being  published  in  response  to  requests 
from  many  interested  parties  for  a  preliminary  summary  as  to  what  the  JIA  will  contain 
when  actually  released  as  a  formal  DoD  Handbook.  Since  the  formal  DoD-wide 
coordination  process  for  the  draft  JIA  Handbook  requires  at  least  an  additional  6  months 
after  it  is  available  in  a  form  ready  for  DoD  coordination,  the  expected  release  of  the 
Official  Handbook  will  not  be  before  the  second  half  of  2000.  The  present  version  of  the 
JIA  Guidelines  is  thus  intended  for  informational  purposes  only  and  is  not  intended  to  be 
an  official  procurement  guide.  It  is,  however,  an  update  of  the  technical  information 
contained  in  a  previously  released  paper  on  the  JIA^j  and  has  been  reviewed  by  the 
technical-team  members  from  the  various  Services.  The  basic  concept  of  the  earlier 
paper  remains  the  same  and  most  technical  changes  are  in  the  nature  of  clarifications  to 
the  previously  published  technical  details.  Some  new  material  has  been  added.  The 
information  has  been  reformatted  to  appear  as  an  official-guidance  document  so  it  can  be 
utilized  as  part  of  the  current  Navy  submission  to  the  ARMY  LOGSA  Office  that  is 
formally  preparing  the  actual  JIA  Handbook.  Statements  made  in  directive  form  will  not, 
of  course,  apply  in  any  official  sense  until  the  Handbook  is  promulgated. 


Comments  from  the  interested  Public  are  not  being  formally  solicited  at  this  time,  but 
Mr.  Jorgensen  will  welcome  questions  and  constructive  comments. 


E-mail:  jorgensenel @ nswccd.navy.mil 


Phone:  301-227-1622. 


1  Jorgensen,  Eric  L.  Proposed  Web-Based  Joint  IETM  Architecture  for  the  Interoperability  of  DoD 
IETMs.  CDNSWC-TSSD-98-10,  10  Aug  1998. 
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Chapter  1.  Scope 

1.1  Scope 

This  Report  provides  technical  guidance  (1)  for  acquisition  of  electronically  presented 
maintenance-related  logistics- support  Technical  Information,  which  includes  both 
Electronic  Technical  Manuals  (ETMs)  and  Interactive  Electronic  Technical  Manuals 
(IETMs),  and  (2)  for  implementation  of  an  environment  for  the  deployment  of 
interoperable  IETM  products.  Within  the  scope  of  this  document,  the  term  IETM  will 
refer  to  both  ETMs  and  IETMs. 

1.2  Objective  of  the  JIA  Development  Effort 

The  objective  of  the  DoD  Effort  leading  up  to  this  guidance  document  was  to  establish  a 
high-level  Joint  IETM  Architecture  (JIA)  to  guide  and  standardize  the  acquisition, 
management,  deployment,  and  display  of  IETMs  that: 

•  will  enable,  for  the  end-user,  maximum  interoperability  in  the  use  of  Technical 
Information  to  meet  the  needs  of  the  Defense  Logistics  community  in  supporting 
the  material  readiness  of  the  DoD  forces;  and 

•  will  also  serve  as  the  basis  for  a  formal  DoD-wide  adoption  of  the  proposed 
approach  in  promulgating  the  required  acquisition  and  field-support  policy. 

To  reduce  the  risks  of  implementation  and  to  demonstrate  utility  of  the  approach,  the 
Study  Team  conducted  a  series  of  FY99  pilot-demonstration  programs^  This  program 
successfully  demonstrated  the  applicability  of  the  Joint  IETM  Architecture  to 
accommodate  IETMs  for  the  whole  spectrum  of  DoD  weapon  systems  and  the  capability 
of  the  entire  range  of  IETM  technical-data  suppliers  of  the  Military  Services  to  provide 
such  JIA  compliant  IETMs. 


2  Fuller,  Joseph  J.  Plan  for  DoD-Wide  Demonstrations  of  a  DoD  Improved  Interactive  Electronic 
Technical  manual  (IETM)  Architecture .  CDNSWC-TSSD-98-006,  July  1998. 
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1.3  Application. 

The  guidance  provided  in  this  Report  is  intended  to  apply  to  all  Department  of  Defense 
IETMs  at  all  maintenance  levels. 

1.4  Background 

The  transmission  and  electronic  presentation  of  digital  data  within  the  Department  of 

Defense  (DoD)  is  quickly  becoming  the  dominant  method  for  communicating  and 

accessing  the  Technical  Information  needed  to  operate  and  maintain  the  military  weapon 

systems  required  to  support  field  operations.  In  response  to  directives  from  the  Office  of 

the  Secretary  of  Defense,  all  of  the  Military  Services  have  ongoing  efforts  to  convert 

paper-based  technical  documentation  into  digital  format.  The  Services  are  replacing 

existing  maintenance  and  logistic-support  Technical  Manuals  with  legacy-data- 

conversion  products  in  the  form  of  Electronic  Technical  manuals  (ETMs)  and  the  newer 

Interactive  Electronic  Technical  Manuals  (IETMs).  Since  this  information  is  needed  to 

sustain  war-fighting  capability  in  Joint  and  multi-unit  operations,  a  uniform  approach 

throughout  DoD  must  be  developed  for  acquiring,  managing,  fielding,  and  viewing  the 

digital  products  in  order  to  support  in-theater  maintenance  of  the  weapon  systems 

supporting  these  Joint  operations.  The  guidance  contained  in  this  document  is  the  result 

of  a  DoD-wide  study  conducted  in  response  to  a  requirement  of  the  Joint  Logistics 

Commanders  Group  for  Communications  and  Electronics  (JCG-CE)  to  develop  a 

n 

common  user  interface  for  this  digitized  information  . 

This  Report  provides  the  guidance  for  a  new  coordinated  procedure  for  acquiring  and 
deploying  IETMs  to  replace  the  current  practice  of  independent  procurement  of 
electronic  Technical  Information  using  divergent  technologies  and  deploying  stand-alone 
formats.  This  new  process,  in  turn,  will  be  guided  by  an  overarching  technical 
Architecture  that  permits  the  IETM  applications  to  interoperate  and  work  together  at  the 


3  Memorandum  for  DUSD  (Logistics)  from  Joint  Logistics  Commanders,  10  June  1997.  Subj: 
Recommendations  to  Modify  Tri-Service  Interactive  Electronic  Technical  Manual  (IETM)  Technology 
Working  Group  Charter  to  Incorporate  Goals  of  the  Joint  Commanders  Group  for  Communications  and 
Electronics  (JCG-CE)  Electronic  Publications  (ETP)  Panel. 
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user  interface,  without  requiring  that  all  programs  employ  the  same  IETM 
implementation,  authoring  system,  or  support  infrastructure.  This  Joint  IETM 
Architecture  (JIA)  is  applicable  for  development  and  deployment  of  IETMs  throughout 
DoD.  Since  the  most  effective  approach  to  acquisition  of  each  individual  IETM  must,  of 
course,  be  based  on  individual  Program  and  Service  requirements  and  restraints,  the 
Architecture  permits  a  wide  range  of  solutions  and  specific  implementations  so  that  such 
procurements  can  be  based  on  sound  business  decisions. 

Thus,  regardless  of  the  source  and  peculiar  format  of  logistic-support  source  data,  the  JIA 
will  provide  the  benefits  of  interactivity  in  Technical  Information  to  any  war-fighter  for 
viewing  and  utilizing  the  Weapon  System  support  data.  The  resultant  process  for 
managing  and  deploying  digital  information  is  directed  at  making  the  most  effective  use 
of  existing  resources  and  will  provide  vitally  needed  IETM  interoperability. 

This  guidance  document  includes  a  comprehensive  initial  release  of  the  JIA  and  guidance 
regarding  Service  Implementation.  It  is  intended  for  immediate  use  in  the  acquisition  and 
deployment  of  IETMs  in  all  components  of  the  DoD. 

1 .4.1  IETM  Interoperability  Problem 

In  1992  the  DoD  issued  several  Military  Specifications  for  Service-wide  use  in  the 
acquisition  of  IETMs  that  are  now  being  acquired  for  many  of  the  DoD’s  major  weapon 
systems.  However,  as  individual  systems  have  matured,  issues  in  the  area  of 
interoperability  among  differing  IETM  presentation  systems  have  arisen.  The  individual 
Services  have  noticed  substantial  incompatibility  between  these  IETM  systems  and  the 
growing  inventory  of  legacy-data  Electronic  Technical  Manual  (ETM)  systems  (to  which 
the  Specifications  were  not  directed).  The  result  has  been  that  although  authoring 
systems  and  the  presentation  systems  developed  for  an  individual  IETM  were 
interdependent,  they  were  incompatible  with  other  IETM  or  legacy-based  ETM  systems. 
An  IETM  authored  by  one  activity  usually  could  not  be  viewed  using  a  presentation 
system  developed  by  another  activity,  nor  could  it  electronically  reference  or  incorporate 
the  legacy-ETM  information  when  needed  to  support  the  Technical  Information. 
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Initially,  this  situation  was  not  a  problem  for  a  weapon-system  Acquisition  Manager  who 
acquired  IETMs,  because  the  developer,  typically  a  prime  contractor,  was  able  to  control 
both  the  IETM  and  the  display  system  for  the  dedicated  user  population  for  any  particular 
weapon  system.  But,  as  the  use  of  IETMs  became  more  widespread,  and  as  they  began  to 
be  deployed  at  multiple  sites,  it  has  become  more  important  to  establish  a  consistent 
infrastructure  to  manage  and  distribute  IETM  updates  to  the  field  sites  and  to  provide 
life-cycle  support  for  the  numerous  types  of  IETMs.  In  this  environment,  the  fact  that 
differing  IETMs  cannot  interoperate  (i.e.,  cannot  be  viewed  on  the  same  standard 
presentation  system,  or  electronically  reference  each  other  to  any  meaningful  level  of 
internal  granularity)  has  become  a  major  impediment. 

1 .4.2  Tri-Service  Approach  to  Solving  the  Problem 

Starting  in  1997,  the  DoD  Tri-Service  IETM  Technology  Working  Group  (IETMTWG), 
then  chartered  by  the  OSD  CALS  Office  of  DUSD(L),  sponsored  a  DoD-wide  study 
based  on  an  earlier  Navy  NAVAIR  Project,  which  developed  a  Navy  IETM  Architecture 
(NIA)®  At  the  request  of  the  OSD  CALS  Office,  the  IETMTWG  expanded  the  NIA 
project  plan  and  approach  into  a  DoD-wide  effort  that  involved  modifying,  prototyping, 
and  testing  a  version  of  the  NAVAIR-initiated  interoperability  methodology  which  could 
be  applicable  to  all  of  the  Services.  The  approach  was  to  utilize  an  expanded  set  of  Tri- 
Service  requirements  and  demonstrate  the  suitability  of  a  DoD  IETM  Architecture  on  a 
spectrum  of  DoD  weapon  systems.  At  the  same  time,  the  proposed  IETMTWG  plan  was 
presented  to  the  Technical  Publications  Sub-panel  of  the  Joint  Commanders  Group  for 
Communications  and  Electronics  (JCG-CE)  as  a  means  of  meeting  some  of  the  major 
goals  of  the  JCG-CE  Publications  Panel.  These  goals  included  the  achievement  of  field 
interoperability  for  IETMs.  The  proposed  approach  was  approved  and  the  JLC 
recommended,  by  a  memorandum  of  10  June  1997,  that  the  OSD  CALS  Office 
implement  this  plan  as  a  joint  effort  of  the  JCG-CE  and  the  IETMTWG.  This  DoD-wide 
effort  technically  started  in  late  1997  and  continued  through  September  1999.  The  OSD 
CALS  office  has  since  been  reorganized  as  DUSD(L)/LRO  (Logistics  Reinvention  Office 

4  Jorgensen,  Eric  L.,  Proposed  Web-based  Architecture  for  the  Interoperability  of  Naval  Aviation 
IETMs,  CDNSWC-TSSD-98-005  March  1 998. 
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of  the  Office  of  the  Deputy  Undersecretary  of  Defense  for  Logistics),  which  is  currently 
the  chartering  activity  for  the  IETMTWG  and  the  sponsor  of  this  JIA  Task. 

1.5  Objective  and  Primary  Goal  for  the  Architecture 

The  objective  for  the  JIA  is  to  establish  a  technical  framework  for  acquisition  and 
deployment  of  the  whole  spectrum  of  Electronic  Technical  Manuals,  so  that  when  the 
sharable  and  interoperable  Technical  Information  is  distributed  to  the  work  location  of 
end-users,  they  will  be  able  to  view  and  utilize  that  data  through  a  common  user 
interface,  no  matter  what  the  authoring  source  or  data  format.  In  so  doing,  the  DoD  will 
be  able  to  establish  a  unified  approach  to  the  acquisition,  management,  and  use  of 
existing  ETMs  and  the  newly  procured  IETMs.  To  obtain  this  objective,  the  overall 
approach  for  JIA  development  has  been  to  base  it  on  the  use  of  existing  COTS 
(Commercial  Off  The  Shelf)  Internet  and  World-Wide -Web  technology.  In  this  light, 
the  JIA  is  not  a  new  or  even  a  redesigned  technical  architecture.  It  is  the  architecture  of 
the  INTERNET  and  the  World  Wide  Web,  profiled  for  DoD  IETMs  and  implemented  on 
secure  DoD  intranets.  As  such  this  document  does  not,  by  design,  contain  many,  if  any, 
new  technical  specifications.  It  is  primarily  a  reference  vehicle  for  shifting  the  inventory 
of  DoD  IETMs  to  a  form  and  format  suitable  for  long-term  use  on  the  Defense 
Information  Infrastructure  (DII),  as  it  emerges  and  is  available  for  the  distribution  and  use 
of  maintenance  and  job-aiding  information. 

The  primary  goal  of  the  JIA  is  to  achieve  end-user-level  interoperability  of  the  IETMs 
delivered  to  and  used  by  the  entire  DoD  Operational  Community.  In  this  context,  an 
ETM  or  IETM  is  defined  as  having  end-user  interoperability  when  it  can  enable  a  user 
with  one  common,  commercially  available  display  device,  such  as  a  portable  personal 
computer: 

(1)  to  view  and  interact  with  Technical  Information  from  any  source  and  of  any 
internal  format;  and 
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(2)  to  automatically  access  and  view,  by  means  of  an  electronic-link  reference  in 
the  displayed  Technical  Information,  additional  information  in  any  other  ETM 
or  IETM  with  which  the  link  connects  him. 

The  JIA  has  been  developed  to  provide  interoperability  for  all  levels  of  Electronic 
Technical  Manuals  including  all  five  established  DoD  ETM/IETM  Classes  from  the 
digitized  page-oriented  Electronic  TMs  to  the  highly  integrated  Interactive  Electronic 
Technical  Manuals.  For  purposes  of  this  guidance  document  and  the  recommendations 
contained  herein,  the  term  “IETM”  will  be  used  to  refer  to  all  classes  of  ETM/IETMs 
whether  the  existing  class  definitions  call  them  ETMs  or  IETMs. 

1.6  Application  of  Guideline  Document  to  the  IETM  Acquisition  Process 

This  guidance  document  describes  the  portions  of  the  Joint  IETM  Architecture  applicable 
to  end-user  interoperability  so  that  three  major  constituencies  can  acquire  and/or  develop 
needed  capabilities  for  an  effective  IETM  by  acquiring  these  IETMs  and  planning  for 
their  in-Service  life-cycle  support  in  such  a  way  that  all  of  the  Technical  Information  they 
contain  is  fully  accessible  by  all  end-users.  The  guidance  contained  in  this  document  has 
specifically  been  designed  so  that  these  three  acquisitions  constituencies  can  separately 
and  independently  procure  their  portion  of  an  overall  IETM  operational  capability. 
Because  of  the  prevalence  of  the  Web-based  architecture  underlying  the  JIA  and  JIA- 
compliant  COTS  software  products,  they  can  be  assured  that  the  many  IETMs  procured 
under  the  JIA  guidance  will  interoperate  when  the  parts  are  brought  together  in  a  specific 
deployment  in  the  field. 

The  three  targeted  constituencies  are: 

(1)  The  creators  and  developers  of  the  IETMs  themselves  (both  with  regards  to  the 
IETM  content  and  the  selection  of  presentation  software  employed  to  display 
that  content); 

(2)  The  developers  of  the  IETM  user- infrastructure  for  both  the  distribution 
infrastructure  and  the  user-site  intranet;  and 
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(3)  The  procurers  of  the  common  user  display  devices  with  the  JIA-compliant 
browser  software  installed  on  these  devices. 

The  guidance  document  is,  of  course,  also  provided  for  the  DoD  Policy  Officials  and 
Acquisition  Program  Managers  who  are  responsible  for  policy  and  direction  of  these 
constituencies. 


The  following  table  highlights  the  relevance  of  the  four  proposed  requirement  areas 
(described  in  detail  in  the  body  of  this  document)  to  the  three  constituencies. 
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Target  IETM  Constituency 


Requirement  Area 

IETM  Developer 

Infrastructure 

Provider 

User  Device 

Provider 

Object  Encapsulation 

&  Component 

Interface 

Principal  Requirement  for 

IETM  Form 

Server  &  Database 

Interface 

Rules  of  Cooperation  between  IETM  developer  and 

Infrastructure  when  server  extensions  and/or  a 

DBMS  need  to  be  installed  as  part  of  delivered 

IETM. 

Common  Browser 

Statement  of  the  capability 

which  can  be  assumed  of 

user-device.  I.e.,  any 

additional  functionality  must 

be  provided  as  a  software 

component  in  the  IETM. 

Statement  of 

minimum 

capability  to 

be  met  in 

procuring 

COTS 

devices 

Addressing  Model 

and  Library  Index 

Used  as  guide  for  preparing 

electronic  address  for 

references  to  other  IETMs 

external  to  IETM  being 

provided.  Also  contains 

requirement  for  index  data 

(i.e.,  metadata)  format. 

Must  provide  for 

server  remapping 

and  Domain  Name 

Services  (DNS). 

Format  of  metadata 

available  for  index 

server. 
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Chapter  2.  Applicable  documents 

Essentially  all  of  the  technical  specifications  for  the  JIA  are  widely  accepted  commercial 

specifications  and  are  documented  for  DoD  in  the  latest  version  of  the  DoD  Joint 

Technical  Architecture^!  In  the  technical  sense  the  JIA  is  not  a  new  architecture  but  is  the 

architecture  of  the  World  Wide  Web  as  applied  to  DoD  intranets  in  accordance  with  the 

JTA.  Additionally  any  guidance  contained  herein  relating  to  an  actual  JIA 

implementation  is  presumed  by  the  to  be  subordinated  to  the  DoD  regulations  and 

requirements  for  communication  security,  Public  Key  Encryption,  and  information 

assurance  which  apply  to  the  environment  in  which  the  IETM  is  utilized,  what  ever  they 
n 

may  be  nowmor  in  the  future. 

Chapter  3.  Definitions 

This  nominal  section  is  included  here  to  parallel  the  numbering  system  of  the  planned 
DoD  JIA  Handbook,  which  will  include  definitions  up  front.  In  this  report,  the  actual 
definitions  and  ACRONYMS  related  to  this  report  are  provided  as  useful  but  not  required 
information  and  are  included  at  the  end  of  this  report  as  Chapter  10. 

Chapter  4.  General  Requirements  for  the  Joint  IETM 
Architecture 

4.1  Overview  of  the  Joint  IETM  Architecture 

The  JIA  is  firmly  based  on  the  proven  and  widely  accepted  Internet  and  World  Wide 
Web  technology,  but  is  directed  at  implementations  on  private,  contained,  and  controlled 
DoD  intranets.  Such  intranets  can  be  configured  as  a  private  DoD  World-wide  network, 
as  a  combat-capable  unit-wide  local  intranet,  or  simply  as  a  group  of  computers  in  close 
proximity,  hard-wired  in  a  local  Ethernet  configuration.  They  can  also  be  configured  as  a 

5  DoD  Joint  Technical  Architecture  (JTA)  Version  2.0,  26  May  1998. 

6  Deputy  SECDEF  Memorandum,  6  May  1999,  Subj:  Department  of  Defense  Public  Key  Infrastructure 
(PKI) 
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single  display  device  (portable  or  workstation  personal  computer)  which  operates  as  both 
an  IETM  browser  and  a  personal  single-user  Web  server.  The  technology  for 
implementing  such  intranets  is  low-risk,  easily  implemented,  and  widely  understood  by 
the  IETM-software  community.  The  proposed  Architecture  is  based  entirely  on  the 
commercial  standards  and  COTS  technology  being  made  available  for  use  on  the  World 
Wide  Web.  A  dedicated  intranet  constituting  a  JIA  IETM  implementation  is  composed 
of  Web  browsers,  Web  servers,  and  a  network  to  connect  them  if  they  are  not  contained 
in  the  same  computer.  As  will  be  described  more  fully  below,  an  IETM  implementation 
on  an  intranet  may  also  include  other  optional  Database  Servers  and  Application  Servers 
in  addition  to  the  principal  HTTP  Web-servers. 

The  overall  concept  of  the  JIA  is  to  utilize  the  group  of  emerging  technologies  that  the 
commercial  marketplace  is  rapidly  adopting  as  the  standard  for  distributable  electronic 
documents.  These,  in  general,  are  based  on  the  technology  of  the  Internet  and  the  World 
Wide  Web.  For  security  and  operational  reasons,  the  DoD  will  not  utilize  the  actual 
public  Internet  or  the  World  Wide  Web  itself,  but  will  employ  essentially  the  same 
technology  and  COTS  products  in  a  private  and  dedicated  DoD  intranet  environment. 

As  noted,  a  major  objective  of  the  JIA  is  to  achieve  end-user  interoperability  of  both 
proprietary  and  legacy  IETMs.  This  will  be  accomplished  by  encapsulating  or  packaging 
them  into  a  common  View  Package  (VP  -  the  name  given  to  the  encapsulated  object  of 
the  IETM)  format,  which  can  be  electronically  distributed  to  DoD  intranets  and 
eventually  viewed  by  an  end-user  employing  a  single  user-information  interface  (i.e.,  a 
Web  browser).  This  process  is  referred  to  in  this  guidance  document  as  "object 
encapsulation";  that  is,  the  process  of  “object  encapsulation”  creates  a  valuable  IETM 
View  Package.  Such  a  capability  will  require  the  employment  of  the  following  technical 
capabilities: 

(1)  an  authoring  framework  which  [regardless  of  which  authoring  tools  are  used] 
can  effectively  create  and  manage  IETM  source  data  and  subsequently  create 
interoperable  IETM  View  Packages  for  delivery  to  the  Government  distribution 
and  user  activities; 
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(1)  an  Infrastructure  that  permits  a  military  agency  to  distribute,  manage,  and 
deliver  these  IETM  View  Packages;  and 

(2)  a  viewing  device  and  a  methodology  for  the  end-user  to  access  and  view  the 
required  Technical  Information,  and  to  retrieve  relevant  data  from  other  IETMs, 
including  those  of  other  Services,  as  necessary. 

In  order  to  achieve  interoperability,  the  interface  requirements  recommended  by  this 
guidance  document,  while  specific,  are  constructed  so  as  to  encourage  innovative  and 
effective  solutions,  especially  in  light  of  the  constantly  expanding  technology  base  of  the 
commercial  environment.  Achieving  this  balance  has  required  some  decisions  that  may 
need  to  be  reexamined  over  time.  However,  whenever  possible,  the  design  will  conform 
to  open  standards  and/or  de  facto  Internet  standards  widely  implemented  by  multiple 
vendors,  with  the  clear  intent  to  maximize  the  use  of  commercially  available  software 
products. 

Figure  1  shows  the  flow  of  an  IETM  and  the  associated  information  access  processes  in  a 
typical  implementation  of  the  JIA.  It  illustrates  the  employment  of  the  JIA  by  the 
original  IETM  developer,  the  management  Infrastructure  repository,  the  user-site  intranet 
server,  and  the  end-user  who  selects  the  next  object  to  view  via  a  point-and-click  Web- 
browser  interface.  The  “Presentation  Component”  referred  to  in  Figure  1  can  be  either  a 
client  or  server  software  component  or  implied  (i.e.,  omitted)  in  the  cases  in  which  they 
are  preinstalled  in  the  standard  browser. 
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Figure  1  -  Flow  of  an  IETM  and  the  Information  Access  Processes  in  the  JIA 
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The  basic  Architecture  is  not  intended  for,  nor  constrained  to,  any  specific  operating 
system,  and  can  be  adapted  to  Microsoft  NT,  DII  COE  (Defense  Information 
Infrastructure  Common  Operating  Environment),  Netscape,  or  Unix  implementations  or  a 
combination  thereof  for  DoD  applications.  Individual  Services  or  Programs  may  restrict 
their  IETM  applications  to  one  of  these  operating  environments,  but  neither  the  JIA  nor 
the  DoD  Joint  Technical  Architecture  (JTA)  upon  which  it  is  based,  requires  a  specific 
operating  system.  In  technical  terms,  the  “glue”  (i.e.,  the  communication  protocol)  that 
holds  an  intranet  together  (as  in  a  JIA  implementation)  is  the  Web  protocol,  HTTP 
(Hypertext  Transfer  Protocol),  operating  over  the  communications  protocol,  TCP/IP 
(both  listed  in  the  DoD  JTA),  not  the  requirement  for  a  standard  operating  system.  Any 
TCP/IP  network  (e.g.,  an  intranet)  can  easily  accommodate  multiple  operating  systems  on 
its  various  server  and  client  computers. 

The  approach  to  developing  a  solution  for  the  problem  of  interoperability  among  IETMs 
from  various  sources  has  been  to  adapt  commercial  and  industry  applications  involving 
electronic  documentation  for  which  there  is  widespread  vendor-product  support  and  these 
are  essentially  all  Web-based  products  to  some  degree.  Taking  into  account  the  rapid 
changes  that  have  been  occurring  in  Internet  technology,  the  JIA  has  been  designed  to  be 
extensible,  flexible,  and  able  to  accommodate  the  predictable  rapid  growth  in  technology 
for  all  aspects  of  the  Internet,  the  Web,  and  the  emerging  electronic-documentation 
applications  being  developed  to  operate  on  the  Web. 

Updates  to  any  guidance  document  for  the  acquisition  of  JIA-compliant  IETMs  must,  of 
course,  be  based  on  a  continuing  study  of  emerging  Military  requirements,  and  compared 
with  the  current  state  of  commercial  technology  and  available  COTS  commercial 
products  to  assure  that  they  still  met  the  DoD  requirements  in  the  future.  The  primary 
areas  relating  to  the  JIA  in  which  requirements  of  the  Military  and  commercial 
communities  may  differ  are  those  involving  communication  security  (COMSEC)  and 
Information  Assurance,  and  the  overall  administratively  imposed  requirements  for 
operational  presence  on  the  DII  (e.g.,  operating  system  limitations,  restrictions  on  use  of 
downloadable  components,  etc.) 
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4.2  Characteristics  of  the  Architecture  Which  Must  be  Preserved  in  Future 
JIA  Implementations. 

As  the  JIA  matures,  certain  requirements  detailed  in  this  guidance  document  are  expected 
to  be  rendered  obsolete  by  events  and/or  emerging-technologies.  In  such  cases, 
developers  and  their  DoD  customers  will  need  to  refine  and  update  some  of  the  technical 
details  discussed  herein.  However,  the  following  non-technical  functional  and 
operational  characteristics  must  be  preserved  even  as  specific  requirements  are  modified 
and  updated  by  technological  progress. 

4.2.1  Characteristics  of  the  JIA  for  the  User 

The  principal  characteristic  of  the  JIA  for  the  user  is  that  it  enables  an  end-user  with  a 
single  display  device  and  a  single  graphic  user  interface  (i.e.,  a  Web  browser)  to  read  and 
utilize  any  DoD  IETM  accessible  to  that  device,  no  matter  which  Service  or  Program 
originated  the  IETM.  In  performing  an  assigned  task,  the  user  will  access  and  view  the 
IETMs  with  either  a  workstation  personal  computer  in  a  shop  environment  or  a  PEDD 
(Portable  Electronic  Display  Device).  The  portable  device  can  be  configured  either  as  a 
network  client  attached  to  the  operational  unit  intranet  or  it  can  be  reconfigured  to  operate 
in  stand-alone  or  detached  mode.  In  either  case,  the  display  of  the  information  on  the 
user  interface  is  identical,  and  the  user  cannot  determine  from  the  look-and-feel  of  a 
screen  display  the  mode  in  which  the  device  is  operating. 

The  major  effect  of  the  JIA  on  the  user  is  that  all  Technical  Information  is  viewed 
through  a  common  (i.e.,  single)  and  very  familiar  Web  browser  interface.  The  JIA 
conforming  IETMs  should  not  employ  externally  launched  viewing  applications 
(typically  called  “helper  applications”)  which  are  not  managed  (i.e.,  structurally  closed 
after  use)  by  the  browser.  Other  elements  of  the  JIA,  while  very  important,  are  intended, 
by  design,  to  be  invisible  to  the  end-user.  To  access  an  IETM,  the  user  will  simply  select 
a  URL  (Uniform  Resource  Locator;  the  form  of  electronic  address  used  by  the  World 
Wide  Web)  using  one  of  the  many  access-screen  or  menu-select  options  available. 
Selection  options  include  such  approaches  as  a  Windows  favorites  list,  explicit  entries  in 
a  predefined  pick  list,  a  pre-assembled  list  of  active  IETMs  on  a  squadron  “Home  Page”, 
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a  hot-spotted  index  graphic,  or  a  standard  job-assignment  form  listing  needed  technical 
references  as  hot  spots.  An  important  characteristic  of  the  JIA  is  that  all  of  these  features 
are  common  practices  borrowed  directly  from  the  World  Wide  Web  community.  From 
the  user’s  perspective,  the  referenced  IETM  content  simply  appears  next  in  the  display- 
device’s  browser  window. 

A  major  characteristic  of  IETMs  that  conform  to  the  JIA  is  that  all  required  browser 
software  components  are  automatically  loaded  (i.e.,  installed)  into  the  browser  with  no 
active  user  involvement.  A  major  benefit  to  the  user  organization  is  that  no  explicit 
software  installations  are  required  to  utilize  an  IETM,  even  with  a  device  employing  a 
brand  new  “out-of-the-box”  JIA-conforming  browser.  Depending  on  the  established 
browser  security  level,  the  user  may,  at  times,  need  to  explicitly  accept  software 
components  that  require  installation,  by  a  single-click  acknowledgment.  Other  than  that 
action,  no  explicit  installation  action  should  be  needed  because  the  browser  installs  the 
components  automatically.  This  is  an  essential  user-friendly  feature  of  the  JIA.  Thus, 
there  should  be  no  need  for  a  trained  and  certified  system  administrator  to  install  user 
software.  This  required  feature  is  a  part  of  the  simplicity  of  the  JIA  approach  and  one  of 
the  largest  potential  cost  savers. 

Another  key  characteristic  of  the  JIA  is  the  focused  use  of  the  primary  Web-based  access 
methodology,  i.e.,  the  “point-and-click”  user  interface.  If  one  IETM  contains  a  reference 
to  another  IETM,  the  user  should  be  able  to  “click  on”  the  highlighted  reference  and  the 
referenced  IETM  should  appear  in  the  same  browser  window  replacing  the  referencing 
information  (assuming,  of  course,  the  referenced  IETM  exists  on  the  user’s  intranet). 

This  second  IETM  can,  in  turn,  reference  a  third  IETM,  etc.  To  return  to  the  original 
IETM,  the  user  can  simply  use  the  “Back”  arrow  on  the  browser  interface,  effectively 
reversing  the  sequence  of  references.  An  important  characteristic  of  such  browser 
management  is  that  the  browser  manages  the  software  and  data  components  utilized 
along  the  way.  The  user  need  not  launch  or  close  out  application  software.  Success  in 
this  area  is  measured  by  the  extent  to  which  the  user  is  not  aware  that  a  browser-managed 
system-clean-up  action  is  going  on.  Modem  Web  browsers  can  handle  many  levels  of 
such  nested  referencing  with  no  performance  degradation,  a  very  powerful  feature.  From 
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the  user  perspective,  the  JIA  is  thus  intended  to  make  the  use  of  disparate  IETMs  as  easy 
and  “seamless”  as  possible  by  use  of  modern  technology.  Because  of  the  nature  of  the 
Web-browser  technology  employed,  the  user  experiences  a  great  deal  of  common  “look- 
and-feel”  in  the  interactive  (navigation-control)  area,  even  if  the  individual  IETM  user- 
interface  for  the  content  varies. 

JIA  implementations  should  also  facilitate  a  common  practice  on  the  World  Wide  Web  of 
employing  search  engines  for  accessing  IETMs  such  as  those  employed  by  the  well- 
known  companies  Yahoo  and  Excite.  The  JIA  Library  Model  and  the  required  standard 
HTML/XML-encoded  Metadata  Package  are  specifically  designed  to  facilitate  the 
inclusion  of  search  engines  on  a  JIA-conforming  intranet.  In  these  search  engines,  the 
user  will  enter  a  “string”  or  list  of  key  word(s)  or  reference  designator(s),  and  the  search 
engine  will  identify  IETM  references  available  on  the  user’s  intranet.  The  JIA  does  not 
specify  a  specific  search  engine,  but  a  rich  selection  of  commercially  available  search 
engines  build  their  indices  from  XML-  and  HTML-encoded  sources  and  can  easily  be 
employed  on  a  JIA  intranet.  The  ability  to  get  all  the  information  needed  to  perform  a 
task  in  a  timely  and  convenient  manner  has  been,  from  the  beginning  of  the  IETM 
concept,  one  of  the  important  performance-enhancing  capabilities  of  IETMs.  This  JIA 
implementation,  using  low  cost  commercially  available  technology,  should  permit  even 
greater  capability  in  this  area. 

4.2.2  Characteristics  of  the  JIA  for  the  IETM  Developer 

The  principal  significance  of  the  JIA  to  the  IETM  developer  is  that  all  software 
components  and  data  needed  to  make  an  IETM  accessible  on  the  JIA  display  device  are 
packaged  into  a  single  digital  product  (i.e.,  the  encapsulated  objects),  which  can  be  easily 
combined  and  installed  as  a  set  of  data  files  (a  View  Package)  onto  an  intranet- server  file 
system  and  subsequently  automatically  delivered  to  the  user  as  the  IETM  is  accessed. 
There  should  be  no  additional  separate  path  for  this  delivery  and  installation  of  user 
software  other  than  the  primary  delivery  path  for  the  encapsulated  object. 

This  object-oriented  methodology  required  by  the  JIA  is  a  primary  benefit  to  the  IETM 
developer  in  that  the  developer  is  free  to  choose  whatever  authoring  and  development 
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environment  he  prefers.  The  JIA  does  not  dictate  how  the  IETM  is  to  be  developed  nor 
what  the  internal  format  of  the  IETM  object  must  be.  The  external  interfaces  are 
specified  but  they  are  in  accordance  with  most  of  the  modern  electronic-document 
authoring  environments  that  are  rapidly  being  adapted  to  operate  on  the  World  Wide  Web 
and,  as  such,  should  operate  equally  well  on  a  JIA-compliant  intranet.  Additionally  it  is 
easy  to  verify  most  aspects  of  JIA  compliance  at  the  contractor’s  site,  in  that  proofing 
tools  for  the  IETM  objects  are  also  easy  to  set  up  in  the  developer’s  facility,  and  it  is  not 
necessary  to  utilize  a  military  environment  to  verify  the  IETM.  The  JIA  browsers  are 
made  up  of  readily  available  software  products,  which  the  authoring  activity  can  easily 
procure  without  going  through  DoD  supply  channels.  The  design  philosophy  for  the  JIA 
is  to  use  the  best  readily  available  commercial  practices  for  developing  and  deploying 
IETM  products. 

While  the  technology  needed  to  bundle  all  of  the  IETM  components  into  a  single  digital 
package  is  complex,  it  is  readily  available  in  off-the-shelf  COTS  Web-based  software 
products.  A  foundation  principal  of  the  JIA  is  that  the  products  developed  for  the  Internet 
can  be  used  unmodified  to  develop  IETM  products  for  a  JIA-compliant  intranet.  This 
process  is  in  sharp  contrast  to  a  conventional  IETM  application  where  the  IETM  product 
is  not  only  a  MILSPEC  custom  format  but  is  delivered  as  two  separate  items,  the  IETM 
content  package  and  the  IETM  presentation-system  software  program. 

4.2.3  Characteristics  of  the  JIA  for  the  DoD  IETM  Distribution  Infrastructure 

The  primary  characteristic  of  the  JIA  to  the  DoD  IETM  Distribution  Infrastructure  is  that 
encapsulated  IETM  View  Packages  can  be  distributed  without  requiring  that  the 
distributing  system  “know”  what  is  inside  the  electronic  capsules.  The  Infrastructure 
activities  can  therefore  consist  simply  of  electronic-package  distribution  centers,  for 
which  the  DoD  has  substantial  experience,  and  not  data-processing  centers,  which  are 
much  more  difficult  to  operate  and  staff. 

Within  the  JIA,  a  complete  set  of  IETM-content  and  associated  presentation  components 
(see  Fig.  1)  is  called  an  IETM  View  Package.  All  View  Package  delivery  to  the  end-user 
network  is  accomplished  through  standard  Web-based  interaction.  A  feature  of  this 
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concept  is  that  the  View  Package  can  be  passed,  unmodified,  from  server  to  server  as  part 
of  the  JIA  electronic-distribution  system.  The  key  JIA  concept  for  creation  and  use  of  the 
Infrastructure  Server  is  that  the  IETM  View  Packages  are  composed  of  self-contained 
digital  objects  that  appear  to  the  Infrastructure  simply  as  large  standard  binary-formatted 
digital  files,  which  can  easily  be  transferred  over  any  intranet  using  common  FTP 
(Internet  File  Transfer  Protocol)  processes  or  transmitted  on  a  common  CD/ROM.  A 
View  Package  can  be  received  from  a  developer,  stored,  forwarded,  and  delivered  from 
one  server  to  another  without  any  need  for  the  Infrastructure  agents  to  know  the  internal 
structure  of  the  View  Package  itself.  Thus,  the  Infrastructure  site  can  function  more  as  a 
supply  center  than  as  an  information-systems  center. 

The  specific  design  of  and  development  of  any  specific  DoD  or  Service  Infrastructure 
was  not  in  the  scope  of  the  JIA  effort  itself.  Such  an  Infrastructure  design  will 
undoubtedly  be  a  complex,  difficult,  but  important  task  that  will  be  complicated  by  the 
impact  it  will  have  on  many  existing  DoD  and  commercial  business  practices.  However, 
this  key  JIA  element,  which  enables  the  IETM  View  Packages  to  be  processed  as  an  item 
of  supply  (with  no  requirement  to  manage  the  internal  content  or  structure  of  the  object), 
will  make  this  task  much  more  manageable. 

4.3  Baseline  Requirements  for  Implementation  of  the  Joint  IETM 
Architecture 

This  section  summarizes  four  categories  of  initial  recommendations  for  the  baseline 
requirements  for  implementation  of  the  JIA  and  for  development  of  JIA-compatible 
IETMs  and  Infrastructure  capability.  These  requirements  are  described  in  more  detail  in 
the  individual  chapters  that  follow. 

In  addition  to  requiring  the  use  of  the  de  facto  standards  of  the  Word  Wide  Web,  such  as 
the  HTTP,  FTP,  and  TCP/IP  networking  protocols  utilized  by  the  Internet  and  by 
virtually  all  commercial  Web-based  intranet  products  and  COTS  systems,  the  JIA  has 
specific  functional  and  interface  requirements  in  four  areas.  These  are:  (1)  Common 
Browser;  (2)  Object  Encapsulation  and  Component  Interface;  (3)  Electronic-Addressing 
and  Library  Functions;  and  (4)  Intranet  Server  and  Database  Interface.  Performance 
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requirements  are  needed  in  all  of  these  areas  to  guide  the  process  of  attaining  and 
providing  for  the  interoperability  to  view  and  access  disparate  IETMs  by  the  end-user. 

4.3.1  Common  Browser 

This  requirement  will  apply  to  the  procurers  of  the  user  PEDDs  (Portable  Electronic 
Delivery  Devices)  and  individual  workstations,  since  installation  of  a  standard  browser  is 
required  for  these  devices.  A  browser  software  component,  which  is  not  included  in  the 
IETM  View  Package,  must  be  pre-installed  on  the  user  device.  However,  the  providers 
of  the  IETM  must  also  be  aware  of  the  details  of  this  minimum  requirement  since  their 
IETM  must  be  developed  in  such  a  manner  that  it  can  be  viewed  using  any  JIA-compliant 
browser.  A  usable  IETM  cannot  exist  without  a  browser,  of  course,  because  a  browser  is 
essential  for  IETM  access. 

Two  products  dominate  the  Web-browser  commercial  marketplace:  Microsoft  Internet 
Explorer  and  AOL/Netscape  (soon  to  be  iPlanet)  Navigator.  The  Common  Browser 
requirement  is  that  the  configuration  of  each  should  be  such  that  they  will  be  functionally 
equivalent  in  any  JIA  intranet.  It  is  the  goal  of  the  JIA  that  either  browser  can  be  used  to 
view  JIA  compliant  IETMs. 

The  minimum  configuration  of  the  browser  to  be  specified  in  the  planned  JIA  Handbook 
will  most  likely  require  some  extensions  to  the  commercially  released  products  which  can 
be  made  via  specified  plug-ins  and  controls;  e.g.,  viewing  capabilities  common  in 
Military  IETMs,  but  not  in  the  general  marketplace,  such  as  CGM  (Computer  Graphics 
Metafile)  or  the  common  PDF  (Portable  Document  Format)  used  for  legacy  TMs. 
Additionally,  for  all  practical  purposes,  the  JIA  will  require  support  for  XML,  HTML  4.0 
with  CSS-2  support,  and  Java-Script.  Thus,  the  JIA  requires  the  use  of  the  newer 
versions  of  these  browsers  at  the  time  that  this  guidance  document  is  being  released. 
While  this  requirement  is  detailed  here  in  some  detail,  it  is  fully  expected  that  imposing 
this  requirement  on  an  actual  user  device  procurement  will  be  a  mere  formality.  Such  a 
procurement  should  require  no  additional  consideration  as  such  basic  browser  capability 
is  expected  to  be  available  on  virtually  any  general  purpose  single  user  COTS  computer 
device  available  form  commercial  sources. 
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4.3.2  Object  Encapsulation  and  Component  Interface 

A  definition  is  needed  for  the  delivery,  transport,  and  structure  of  the  integrated 
collection  of  software  components  and  data  contained  in  the  IETM  View  Packages. 

In  addition  to  IETM  content  and  presentation  components,  the  encapsulated  object  must 
include  interfaces  between  multiple  components  when  they  exist,  and  the  automated 
mechanisms  for  placing  the  IETM  on  the  targeted  intranet.  It  must  also  include  the 
capability  to  automatically  install  these  components  on  a  presentation  device  in  a  manner 
sufficiently  simple  so  that  no  professional  system  administrator  is  needed  at  the  user  site. 
From  an  architectural  viewpoint,  actual  Object  Encapsulation  can  be  ordered  so  as  to 
either  operate  at  the  user  workstation  (i.e.,  using  the  client  software)  or  at  the  server 
installation.  The  JIA  Object  Encapsulation  Process  is  described  in  the  more  detailed 
chapter  following  in  terms  of  four  Architectural  Types:  two  client-centered  and  two 
server-centered.  These  are  designated  respectively  as  Cl,  C2,  SI,  and  S2,  and  are 
described  in  Chapter  6.  Any  of  these  types  (or  a  combination  thereof)  is  an  allowable 
Object  Encapsulation  approach  under  the  JIA.  This  Object  Encapsulation  requirement 
constitutes  the  primary  guidance  required  to  document  to  the  IETM  developer  in  what 
logical  form  the  DoD  customer  requires  the  IETM  View  Package  be  prepared  and 
delivered  to  the  Government. 

4.3.3  Electronic-Addressing  and  Library  Functions. 

This  is  the  overarching  requirement  that  holds  the  collection  of  IETM  information 
together  by  means  of  digitally  encoded  and  executable-link  references.  The  requirement 
itself  will  define  the  syntax  and  mechanism  for  building  and  executing  the  automated 
links  to  the  IETM  content  and  the  IETM  presentation  software.  Two  additional  areas 
regarding  administration  and  enforcement  of  the  recommendations  are  needed  so  that  the 
enterprise-wide  addressing  concept  will  work.  The  Electronic  Addressing  and  Library 
Model  requirement  will  define  these  aspects,  which  will  include  the  administration  and 
allocation  of  the  DoD-wide  IETM  “address  space”,  the  actual  indexing  or  URL-based 
electronically-processible  numbering  system  to  which  all  the  Services  and  their  suppliers 
must  subscribe.  The  requirement  will  also  discuss  the  important  area  of  the  library  model 
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or  the  search-and-access  mechanism,  which  can  be  used  to  perform  an  intelligent  content- 
based  access  to  another  IETM  when  the  exact  specific  locator  (i.e.,  a  URL)  is  not  known. 
To  support  the  proposed  Library-Search  functionality,  the  requirement  will  also  specify 
and  require  metadata  files  (encoded  within  a  ‘meta’  tag  in  HTML  or  XML),  that  will 
serve  as  the  primary  searchable  indices  associated  with  each  IETM. 

A  specific  technical  and  administrative  impact  in  any  real  implementation  of  this 
addressing  model  is  that  the  JIA  utilizes  a  concept  of  virtual  URLs  which  in  turn  imposes 
a  requirement  on  the  Infrastructure  to  processes  the  associated  Domain  Name  Service 
(DNS)  to  assign  the  virtual  URLs  in  an  IETM  to  a  specific  server  on  which  the  referenced 
IETM  is  located  in  terms  of  its  network  address  on  the  intranet  being  utilized.  This  is  not 
a  technically  difficult  issue,  as  some  DNS  is  needed  for  any  intranet  to  operate,  but  there 
may  be  an  additional  IETm  related  administrative  burden  to  add  an  additional  IETM 
specific  DNS  to  an  existing  network  to  execute  JIA  compliant  IETMs.  This  is  described 
in  more  detail  in  Chapter  7. 

4.3.4  Intranet  Server  and  Database  Server  Interface 

Lor  those  IETMs  that  require  the  services  of  both  an  Intranet  Server  and  a  user-site 
Database  Server,  the  IETM  supplier  must  provide  the  proper  software  extensions  to  the 
basic  JIA  intranet  Web-server  for  access  to  the  Database  Server  if  they  are  not  already  in 
place.  This  requirement  identifies  the  need  for  cooperation  between  the  constructors  of 
the  end-user  intranet  Infrastructure  and  the  IETM  provider,  who,  in  turn,  need  to  establish 
the  interfaces  and  protocols  involved.  The  JIA  is  designed  to  recognize  the  fact  that,  in 
most  cases,  it  will  be  necessary  to  install  software  using  conventional  system- 
administration  practices  on  fielded  servers  in  order  to  achieve  needed  functionality.  (Note 
that  this  will  not  to  be  the  case  for  the  components  fielded  on  JIA-conforming  user 
browsers.)  The  guidance,  detailed  more  fully  in  Chapter  8,  documents  the  requirements 
that  an  IETM  provider  must  take  into  account  when  proposing  or  delivering  such  a 
capability  for  a  JIA  intranet. 
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4.4  Communications-Security  and  Information-Assurance  Requirements 

All  IETMs  developed  to  be  JIA  compliant  must  also  be  designed  to  be  usable  within  the 
DoD  Information  Infrastructure  as  it  matures  and  becomes  more  available  for  Logistics- 
Support  operations.  The  functional  area  of  using  and  deploying  of  IETMs  in  the  field 
will  be  one  of  these  Logistics-Support  areas,  and  will  probably  form  a  part  of  what  is 
being  called  the  Global  Combat  Support  System  (GCSS).  As  such,  the  IETM 
applications  will  inherit  the  requirements  for  applications  on  the  GCSS  (or  the  name 
ultimately  given  to  the  collection  of  Logistics-Support  Applications  of  the  DII), 
especially  in  the  communications-security  and  information-assurance  area.  Note  that 
these  requirements  apply  to  unclassified  IETMs  as  well  as  classified  IETMs. 
Requirements  for  DoD  IETMs  classified  Secret  and  above  will  be  in  addition  to  these 
requirements  and  are  not  covered  in  this  guidance  document. 


The  specific  communication-security  technologies  involved,  and  accordingly  the 
associated  policies,  are  subject  to  constant  revision  over  the  next  few  years.  However, 
communication-security  requirements  of  some  kind  will  certainly  exist  and  IETMs  will 
be  required  to  conform  to  those  requirements.  Thus,  it  is  likely  that  most  of  the  specific 
IETM  requirements  and  those  of  the  associated  Infrastructure  implementation  will  apply 
to  the  network  elements  (i.e.,  browser  implementation  and  settings,  and  Web  servers)  and 
not  to  the  specific  IETM  View  Package  itself.  That  is,  the  communication  and 
information-assurance  security  will  involve  user  and  server  authentication  and  will  be 
layered  around  the  IETM  accessing  and  viewing  processes;  and  will  not  be  part  of  the 
IETM-specific  View  Packages  or  the  actual  implementation.  The  principal  exception  to 
this  statement  is  that  the  downloadable  software  components  involved  in  an  IETM 
(including  diagnostic  routines  and  software  agents)  should  be  digitally  signed  and  issued 
a  certificate  by  one  of  the  official  IETM  management  activities.  These  activities  would 
be  the  same  activities  that  would  authorize  or  issue  the  IETM  vURLs  referred  to  in  the 


Addressing  Model  Requirement  discussed  in  Chapter  7.  It  is,  however,  very  clear  that  in 
accordance  with  emerging  DoD  policy^any  security  mechanism  implemented  in  any 
DoD  IETM  must  be  limited  to  those  that  employ  only  the  certificates  issued  by  the 
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official  DoD  Public  Key  Infrastructure  (PKI).  In  other  words,  proprietary  or  any  other 
non-DoD  security  methodologies,  no  matter  how  much  sense  they  make,  should  not  be 
used  if  they  in  any  way  require  the  administration  of  a  certificate  (i.e.,  digital  key) 
program  which  provides  ujnique  (i.e.,  other  that  the  official  DoD  PKI  issued)  certificates 
to  users. 

4.5  Requirement  Permitting  IETM  Use  in  a  Stand-alone  Environment 

A  unique  feature  expected  of  a  typical  Military- JIA  Intranet,  as  opposed  to  more 
conventional  Private-Sector  intranets,  is  the  capability  of  operating  PEDDs  (or  other 
portable  display  devices)  as  stand-alone  devices.  Portable  devices  are  more  likely  to  be 
disconnected  from  any  network  during  the  time  when  an  IETM  is  actually  being  viewed 
in  support  of  a  maintenance  task.  In  many  cased  the  portable  user  device  is  connected  to 
the  intranet  network  only  occasionally,  for  the  purpose  of  receiving  needed  information 
or  for  purposes  of  configuration  management.  These  incidents  will  involve  the 
downloading  of  new  or  updated  information,  as  well  as  the  uploading  of  feedback 
reports,  the  ordering  of  parts,  and  the  reporting  of  other  logistics  information. 

4.5.1  Occasionally-Connected  User  Devices 

Since  it  is  possible  to  carry  out  all  the  functionality  of  a  distributed  intranet,  using  a 
single  device,  by  installing  a  personal  Web-type  server  on  the  portable  device,  those 
applications  are  considered  conforming  to  the  JIA.  If  needed,  it  is  also  possible  to  install 
other  servers  that  might  be  needed  for  an  advanced  IETM.  For  some  database-oriented 
IETM  applications,  when  the  PEDD  is  used  in  stand-alone  mode,  there  will  be  a  need  to 
explicitly  install  on  the  PEDD  the  database-management  system  (DBMS)  which  performs 
the  database-server  function. 

To  be  fully  JIA  compliant,  as  applications  are  developed,  a  substantial  requirement  exists 
to  build  configuration-management  facilities  into  the  downloading  system  that  is 
supplying  data  to  the  user  devices.  However,  with  these  self-contained  intranet  features 
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in  place,  it  will  be  possible  to  access  any  object  loaded  onto  the  device  in  exactly  the 
same  fashion  as  from  the  Site  Server. 

4.5.2  Dual-Mode  IETMs  and  the  JIA 

Two  options  also  exist  for  viewing  IETMs  in  a  stand-alone  environment  and  which  do 
not  require  the  installation  of  a  Web  server  on  the  stand-alone  device.  These  are 
considered  in  this  guidance  to  be  compatible  with  the  JIA  concept.  In  these  cases, 
individual  Services  may  sponsor  dual-use  implementations  of  some  IETMs,  utilizing  a 
stand-alone  version  for  primary  Service  use,  and  at  the  same  time  maintaining  the  option 
to  incorporate  the  IETM  unmodified  in  a  JIA-compliant  intranet  (and  hence  achieve  a 
JIA-compliant  IETM)  with  little  or  no  additional  effort. 

One  approach  to  such  dual-mode  use  is  to  take  advantage  of  the  fact  that  both  the 
Netscape  and  Microsoft  Web  browsers  can  directly  access  a  file  system  on  a  local 
computer  without  using  a  server  (including  a  CD/ROM  mounted  on  the  computer’s  file 
system).  These  applications  are  commonly  called  “disk  webs”,  and  are  used  by  book 
publishers  to  distribute  CD/ROM  versions  of  their  publications.  This  approach  is,  in 
general,  limited  to  static  presentations  such  as  book  replicas.  A  disk  web  can  limit  its 
internal  URL  references  to  a  restricted  syntax  called  “relative  addressing”  in  which  the 
server  is  implied  as  the  “current  server”  and  is  not  actually  specified  in  the  URL.  In  this 
case,  it  is  possible  to  mount  the  same  IETM  system  on  a  JIA-compliant  server  or  on  a 
local  computer’s  file  system. 

A  second  option  for  JIA-conforming  dual-use  IETMs  involves  a  legacy-data 
implementation  and  format  for  which  an  additional  JIA-conforming  Web-enabled 
presentation  component  has  been  developed  that  requires  no  alterations  of  the  original 
electronic  information  for  presentation  on  an  intranet.  In  such  a  case,  the  same 
information  can  still  be  viewed  on  the  original  stand-alone  viewer  or  on  a  JIA  browser. 

4.6  Building  an  Integrated  Product-Support  Database 

While  out  of  the  official  scope  of  this  guidance  document,  it  is  also  herein  recommended 
that  the  Joint  IETM  Architecture  be  considered  for  possible  application  to  fielded 
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weapon-system-support  applications  other  than  IETMs,  such  as  job-site  training, 
diagnostics,  and  logistics  support.  The  Joint  IETM  Architecture  can  apply  to  any  of  the 
components  of  what  might  be  called  an  Integrated  Product  Support  Database  (IPSDB). 
Using  a  JIA  approach,  such  a  de  facto  IPSDB  could  be  developed  without  employing  a 
total  custom  formally  integrated  system  redesign.  Functions  which  could  benefit  strongly 
from  the  application  of  the  JIA  include  training  products  used  to  support  a  weapon 
system  in  the  field,  on-line  parts-ordering  functions,  parts  information,  and  remotely 
operated  diagnostics  procedures  traditionally  known  as  test  program  sets.  In  developing 
integrated  support  for  a  weapon  system,  it  should  be  the  DoD  position  to  discourage  the 
development  of  disparate  support  products  for  individual  weapon-system-support 
functions.  Instead,  it  is  recommended  that  a  strategy  be  developed  for  using  the  proposed 
unified  IETM  Architecture  to  provide  a  coordinated  IPSDB  functionality,  which 
incorporates,  fielded  technical  training,  diagnostics,  and  logistic  support  products.  This 
can  be  accomplished  without  the  expense  and  substantial  effort  of  an  integrated  system 
design.  All  that  may  be  needed  to  start  such  a  development  is  the  enforcement  of  an 
addressing  model,  such  as  that  proposed  for  IETMs,  which  would  permit  independent 
applications  to  form  a  “web”  of  content  related  linkages.  This  may  in  fact  be  all  the 
needed  information  to  effect  a  meaningful  integration  as  far  as  the  user  in  concerned.  For 
example,  he  can  get  his  parts  data  or  a  refresher  training  module,  from  the  IETM  and 
return  with  a  simple  clicks  or  a  “back”  function.  The  family  of  general-purpose 
commercial  products  being  developed  utilizing  Internet  World  Wide  Web  technology  can 
provide  all  the  functionality  needed  in  these  applications.  These  can  be  adopted  instead 
of  the  “Stove-pipe”  application  software  traditionally  employed  by  individual  weapon- 
system  suppliers  in  the  development  of  custom  DoD  product- support  systems. 

4.7  Defining  the  JIA 

The  following  four  chapters  detail  the  individual  requirement  that  define  the  JIA  as 
summarized  in  this  introductory  chapter.  Chapter  9  closes  with  an  additional  proposed 
requirement  that  may  be  needed  to  assure  that  the  ability  to  access  a  JIA  compliant  IETM 
is  also  the  ability  to  utilize  the  JIA  compliant  IETMs  in  support  of  a  common  operations 
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or  maintenance  task.  This  chapter  details  a  recommendation  for  achieving  a  meaningful 
level  of  common  “look  and  feel”  for  the  IETMs  developed  under  the  JIA  guidelines. 

Chapter  5.  Common  Browser 

The  approach  of  the  Joint  IETM  Architecture  is  to  use  de  facto  Industry  Standards,  and  in 
the  case  of  the  JIA  browser,  to  be  able  to  use  de  facto  software  to  the  extent  that  the 
browser  provided  for  a  device  purchased  in  a  routine  computer  store  is  adequate  to  serve 
as  the  starter  browser  for  a  JIA  IETM..  What  little  customization  that  may  be  needed  can 
be  accomplished  after  the  fact  by  visiting  a  DoD  “plug-in  site”,  which  containes  the  auto¬ 
install  provision  for  the  needed  IETM  plug-ins  such  as  the  latest  PDF  viewer  or  a 
standard  graphics  viewer.  It  is  expected  that  to  the  procurer  of  user  devices,  the 
requirement  for  a  JIA  browser  will  be  essentially  a  non-issue.  Accordingly,  requirements 
for  a  common  browser  are  based  on  the  Industry  practice,  in  which  two  particular 
commercial  products  together  have  captured  essentially  the  entire  Web-browser  market. 
While  it  is  possible  to  develop,  assess,  and  evaluate  a  long  list  of  needed  and  desirable 
requirements  for  the  common  IETM  browser,  such  an  exercise  would  serve  little  purpose 
in  light  of  economic  and  marketplace  realities  of  such  de  facto  standard  products.  New 
Web  browsers  are  complex  software  products  that  are  very  expensive  to  develop. 
Furthermore,  products  currently  being  offered  in  the  marketplace  free  of  charge 
effectively  preclude  development  of  additional  commercial  general-purpose  browser 
products.  At  this  writing,  these  two  products  are  AOL/Netscape  Navigator  (soon  to  be 
renamed  as  the  iPlanet  Browser  to  reflect  a  new  alliance  with  Sun  Microsystems)  and 
Microsoft  Internet  Explorer.  Except  for  a  few  proprietary  capabilities,  these  two  products 
are  functionally  identical.  For  the  traditional  HTML  Web  pages  that  dominate  the 
WWW,  they  perform  similarly. 

This  Common  Browser  requirement  over  time  will  likely  through  the  official  DoD  JIA 
handbook  specify  the  appropriate  version  of  each  of  the  two  dominant  commercial 
browser  products  cited  and  a  set  of  standard  extensions  (i.e.,  controls  and/or  plug-ins)  to 
these  browsers.  The  specifics  will  be  updated  over  time.  These  extensions  will  most 
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likely  include  common  DoD  data  viewers  for  file  formats  such  as  PDF,  CGM  Version  4 
Web  Profile  for  Graphics,  CALS  raster  images,  and  possibly  a  CALS  Table  viewer. 

What  is  important  in  this  Common  Browser  requirement  to  IETM  developers  is  the 
situation  that  the  inherent  capabilities  of  the  JIA-compliant  browser  will  include  basic 
presentation  methods,  either  intrinsic  to  the  commercial  browser  or  added  to  meet  JIA 
requirements,  so  that  the  component  portion  of  an  Encapsulated  Object  (View  Package) 
can  be  treated  as  though  already  installed  on  the  presentation  device.  Accordingly,  these 
particular  browser  components  should  not  be  included  in  the  IETM  View  Package. 
Currently  built-in  browser  support  includes  components  such  as  HTML  4.0  (HyperText 
Markup  Language)  layout,  GIF  (Graphics  Interchange  Format)  and  TIFF  (Tagged  Image 
File  Format)  viewers;  and  JPEG  (Joint  Photographic  Experts  Group)  display. 

The  goal  of  the  JIA  is  that  all  DoD  IETMs  be  compatible  with  both  the  Internet  Explorer 
and  Navigator/iPlanet  browser  products. 

At  the  time  of  the  writing  of  this  guideline  document,  there  remain  some  issues  regarding 
these  two  browsers  and  the  emerging  DoD  communication  security  requirements.  Only 
one  version  of  the  Netscape  browser  has  been  approved  as  meeting  the  new  PKI  security 
requirements  at  this  point.  This  security  issue  is  much  broader  that  the  use  of  Web 
browsers  for  IETMs  on  the  GCSS  (Global  Combat  Support  System),  as  is  effects  the  use 
of  such  browsers  for  any  applications  on  the  GCSS.  It  is,  however,  the  expectation  of  the 
vendors  and  Defense  Department  officials  that  these  issues  will  be  resolved  in  the  near 
future  and  that  both  browsers  will  be  approved  for  use  on  the  GCSS. 

Chapter  6.  Object  Encapsulation  and  Component  Interface 

A  fundamental  principle  underlying  the  Joint  IETM  Architecture  is  that  developers  of 
IETMs  can  deliver,  as  a  single  View  Package,  all  capability  in  the  form  of  Technical 
Information  and  software  components  needed  to  install  and  use  an  IETM  on  a  standard 
DoD  Intranet.  This  requirement  provides  the  IETM  suppliers  with  a  description  of  the 
framework  in  which  they  are  to  package  and  deliver  the  digitally  encoded  IETM.  This 
View  Package  will  contain  both  content  and  software  components  that  have  been 
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combined  into  Encapsulated  Objects,  and  delivered  as  a  contract  package  for  electronic 
archiving  or  subsequent  store-and-forward  management.  Consequently,  there  is  no  need 
for  separate  delivery  of  an  IETM  presentation  device  or  piece  of  viewer  software  for 
separate  installation  onto  the  user’s  presentation  device.  Rather,  the  View  Package  will 
contain  intrinsically  the  capability  to  be  automatically  installable  onto  the  end-user 
intranet  at  the  time  it  arrives  at  the  intranet.  The  specific  methodology  for  accomplishing 
this  is  not  specified  in  this  guidance  other  than  to  require  that  it  must  operate  on  the  two 
JIA  target  browsers  and  a  generic  Web-server  including  the  capability  of  Microsoft 
Internet  Information  Server  and  the  Netscape  Suitespot  Server. 

6.1  Core  Object  Encapsulation 

This  requirement  is  applicable  primarily  to  IETM  developers;  i.e.,  to  those  involved  in 
the  preparation  of  IETMs  for  delivery  to  the  Government.  Fundamentally,  it  provides 
that  all  components,  content,  and  software  be  encapsulated  into  a  single  IETM  View 
Package  for  transport  to  the  user  intranet  in  a  form  which  is  accessible  and  viewable  on 
an  end-user  presentation  device.  It  applies  irrespective  of  the  method  employed  for 
information  delivery,  whether  on-line  or  via  a  high-density  data  bundle  such  as  a 
CD/ROM. 

The  Encapsulated  (data  and  software)  Objects  will  eventually  be  delivered  by  the  Service 
Infrastructure  to  the  field-user  activities  as  though  they  were  simple  binary  data  packages. 
These  packages  will  be  treated  by  the  Infrastructure  as  file-oriented  data  destined  for  a 
DoD  Site  intranet  Web-server.  The  View  Packages  will  appear  simply  as  a  generic 
“bucket  of  sequenced  bits”  that  are  processible  by  the  server,  but  for  which  the  content  is 
of  no  concern  to  the  Infrastructure.  The  Infrastructure  activity  need  only  assure  that  these 
bits  remain  packaged  together.  The  View  Package  is  a  set  of  industry- standard  binary 
files,  each  of  which  is  assigned  a  JIA  notional  locator  (e.g.,  a  URL,  or  Uniform  Resource 
Locator,  conforming  to  the  JIA  Electronic  Addressing  Model)  that  contains  sufficient 
information  to  support  its  installation  as  data  in  the  Intranet  Server  file  system  (See 
Chapter  7  for  details).  Until  the  point  of  receipt  by  the  intranet  server,  the  View  Package 
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is  processed  as  a  single  object.  Only  at  the  server  is  the  View  package  broken  down  into 
its  constituent  parts. 

The  complexity  and  degree  of  integration  of  these  View  Packages  will  vary  greatly 
among  differing  IETMs.  Some  will  simply  be  a  two-part  collection  of  one  software 
component  and  one  data  set.  The  simplest  form  will  be  a  single  set  of  data  with  all  of  the 
needed  software  contained  in  the  standard  JIA  browser.  In  other  forms,  a  system  of 
software  components  and  possible  multiple  data  sets  will  be  spread  out  among  several 
servers  and  the  browser  device  when  the  IETM  is  operational.  For  example,  this  latter 
case  might  apply  when  there  are  background  software  agents  that  might  be  concurrently 
performing  diagnostics  and  system  monitoring.  Another  emerging  technology  requiring 
the  use  of  more  complex  IETM  Encapsulated  Objects  entails  the  use  of  software  agents 
acting  as  an  intelligent  mentors  which  insert  training  aids  into  the  job-aiding  presentation 
when  the  agent  (a  computer  program)  determines  they  are  needed.  Between  these 
extremes  is  a  spectrum  of  complexity,  each  level  requiring  a  somewhat  different  object- 
encapsulation  approach.  The  “object”  nature  of  such  View  Packages  is  that  all  the 
intelligence  required  to  construct  the  operational  IETM  on  the  target  intranet  is  contained 
within  each  View  Package  object  itself.  Thus,  there  is  no  single  standard  for  the  internal 
constructs  of  the  View  Package  in  the  JIA,  and  the  absence  of  such  a  standard  is  a  distinct 
characteristic  of  the  object-oriented  approach  used  by  the  JIA  in  defining  requirements. 

6.2  Object  Encapsulation  for  Various  JIA  Architecture  Types 

In  practice,  the  implementation  of  an  IETM  intranet  may  be  simpler  (as  is  the  case  with 
basic  HTML  pages)  or  more  complex  (as  is  the  case  with  most  custom  servers)  than  that 
implied  by  the  baseline  operational  flow  of  Encapsulated  Objects  (Figure  1)  described  in 
the  introductory  chapter  of  this  guidance  document.  The  following  breakdown  of 
anticipated  IETM  View  Packages  by  Architecture  Type  is  presented  in  order  to 
categorize  these  variants  and  to  provide  guidance  that  is  more  specific  in  the 
implementation  of  these  variants.  These  variants  have  been  developed  to  reflect  the 
reality  of  the  differing  approaches  currently  taken  to  implement  large  Web  sites  in  the 
commercial  sector.  They  are  not  intended  to  be  a  new  specification  of  how  IETMs 
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should  be  developed  differently.  Any  particular  IETM  intranet  implementation  will 
typically  contain  a  mixture  of  these  Types.  The  four  Architecture  Type  categories 
described  represent  a  continuous  spectrum  of  variation  rather  than  a  discontinuous  set. 
Thus,  for  some  applications,  it  will  be  difficult  at  times  to  categorize  all  implementations 
precisely.  However,  the  overall  guidance  applies  in  all  cases. 

Definitions  of  these  Architecture  Types  are  given  in  Table  1.  The  Type  definitions  are 
grouped  into  two  categories: 

(1)  IETM  Architecture  Types  Cl  and  C2.  With  Type  C  Object  Encapsulation,  the 
various  components  of  the  IETM  come  together  in  the  browser  (i.e.,  client) 
software.  The  server  merely  manages  the  separate  components  for  file  and 
delivery  purposes.  No  actual  computations  are  performed  on  the  site  Server. 
These  Types  require  only  a  browser  and  a  generic  HTTP  based  Web-server. 

(2)  Architecture  Types  SI  and  S2.  For  Type  S  Object  Encapsulation,  the 
computational  process  is  hosted  on  the  site  Server  where  the  IETM  software 
comes  together  with  the  IETM  Technical  Information  and  the  server  is  the 
location  where  the  computational  processes  are  accomplished.  Only  the  last  step 
of  rendering  an  image  on  the  screen  is  performed  by  the  browser.  For  these 
server-centric  Types,  the  technology  for  incorporating  the  additional  servers  into 
a  Web-type  environment  is  less  mature  with  respect  to  standardization,  and 
available  commercial  products  are  much  more  diverse.  This  segment  of  the 
market  place  is  just  now  emerging,  and  it  is  much  dominated  by  proprietary 
products.  However,  the  products  have  been  developed  to  meet  real  commercial 
requirements  and  are  very  powerful  for  highly  interactive  presentations.  They 
are,  in  particular,  effective  for  large-scale  IETMs  which  are  frequently  updated 
from  an  authoring  database. 
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Table  1  -  IETM  Architecture  Types 


Type 

Characteristics 

Examples 

Type  Cl: 

HTML/  XML  page(s)  with  only  browser- 

HTML  with  Java  script,  GIF, 

Basic 

HTML/ 

resident  components.  Requires  no 

JPEG,  frames 

component  licensing.  Most  will  work  on  any 

browser.  Includes  HTML  4.0  scripts. 

XML  +  CSS  or  XSL  Style  Sheets 

XML  Pages 

Client  processing  only.  “Plain  vanilla”  HTTP 

server. 

When  standardized  by  JIA  Policy, 

PDF  and  CGM  files. 

Type  C2: 

Viewer-specific  data  set  plus  custom 

.docf  iles  plus  MS  WordView 

Simple 

automatically  downloadable  non-HTML 

control 

Down- 

viewing  component 

Legacy  Systems  reprogrammed  as 

loadable 

Component 

Uses  “plain  vanilla”  HTTP  server. 

custom  browser  or  presentation 

system  operating  inside  a  standard 

browser  shell/container. 

Type  SI: 

Two-tier  architecture  in  which  Web  page 

MS  Front  Page  Webs 

HTML  Plus 

includes  reference  to  server  application(s). 

MS  Design-time  Controls 

Application 

Server 

which  must  operate  before  page,  is  delivered 

to  client  as  HTML/  XML.  Data  and 

components  managed  on  server.  Utilizes 

File  Base  on  Server. 

Requires  HTTP  server  with  S/W  components 

for  server-side  computations.  Permits  both 

client  and  server  processing. 

CGI  Server  Apps 

DynaWeb 

Type  S2: 

Three -tier  architecture  that  includes  a  Web 

Raytheon  AIMSS  4.0 

HTML  with 

page  server  with  pages  functioning  like  a 

Boeing  Data  Courier 

Database 
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Properties  of  Client-Based  Architecture  Types 

Architecture  Types  Cl  and  C2  share  the  common  important  properties  of  not  requiring 
installation  or  operation  of  unique  software  on  the  server.  Thus,  the  server  can  be  treated 
as  an  electronic  bookshelf.  As  far  as  the  server  is  concerned,  the  two  parts  of  a  Type  C2 
Encapsulated  Object  (the  content  and  the  associated  software  components)  are  simply 
treated  as  files.  Type  Cl  Encapsulated  Objects  have  no  included  software  components 
that  need  to  be  downloaded  from  the  server.  Additionally,  any  contemporary  HTTP 
server  can  be  employed  and  it  does  not  matter  what  operating  system  is  employed.  Thus, 
for  Type  Cl  and  C2  IETM  applications,  interoperability  is  very  low-risk  in  the  sense  that, 
with  these,  any  IETM  View  Package  can  be  accessed  using  any  server.  For  IETMs  of 
Types  Cl  and  C2,  only  a  generic  server  is  required  and  no  JIA-specific  server 
requirement  is  required.  Both  Types  are  considered  pure  encapsulated-object  Types; 
however,  for  Type  Cl,  the  component  part  of  the  object  can  be  implied  (i.e.,  omitted),  as 
its  presence  can  be  treated  as  preinstalled  on  any  JIA-compliant  browser  and  need  not  be 
included  in  the  transported  IETM  View  Package.  For  Type  C2  encapsulation,  the 
software  component  is  downloaded  from  the  server  to  the  browser  the  first  time  the 
IETM  is  accessed. 

The  Type  C  definitions  are  closely  tied  to  specific  versions  of  HTML  and  XML,  a 
situation  that  is  further  clarified  in  this  document.  HTML/XML  is  herein  specified  as 
employing  both  HTML  version  4.0  and  XML  version  1.0,  both  International  W3C 
(World  Wide  Web  Consortium)  recommendations  (i.e.,  de  facto  standards)  which  have 
been  formally  approved.  An  important  consideration  behind  this  decision  is  that 
essentially  all  the  major  software  vendors  support  these  W3C  recommendations,  whereas 
no  complete  agreement  exists  as  to  support  of  delivered  products  based  on  the  previous 
HTML  3.2.  The  XML  standard  has  elicited  widespread  vendor  promise  of  support  as  a 
user-extensible  expansion  of  HTML.  XML  lags  behind  HTML  4.0  in  maturity,  but  the 
W3C  recommendation  is  sufficiently  complete  so  that  software  has  been  provided  by 
major  vendors,  and  shows  promise  of  becoming  a  Web-based  tagging  standard  that  is 
more  suited  to  the  preparation  of  complex  IETMs  than  HTML.  In  particular,  it  will  be 
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much  easier  to  convert  the  large  DoD  inventory  of  SGML-tagged  source  data  to  XML  for 
a  JIA-compliant  presentation  than  it  is  to  convert  it  to  HTML. 

6.2.1  Properties  of  Server-Based  Architecture  Types 

For  Type  SI  and  S2  IETM  applications,  particularly  for  the  server  application  software, 
current  de  facto  Industry  practices  for  encapsulating  the  differing  Application  Server 
packages  are  much  less  certain  to  achieve  the  stage  of  W3C  Recommendation.  Several 
company-proprietary  approaches  are  available  for  standardizing,  such  as  Microsoft’s 
design-time  controls,  and  Active  Server  Pages  (ASP).  Additionally,  a  variety  of  third- 
party  middle-ware  products  exist  to  perform  the  integration  of  Web-Servers  and 
Application  Servers.  However,  the  technology  and  the  state  of  de-facto  COTS  industry 
standards  are  not  sufficiently  mature  at  this  time  to  propose  any  one  of  them  as  a  DoD 
standard,  a  practical  necessity  if  all  IETMs  are  to  operate  on  a  single  server. 

However,  this  is  not  the  only  method  to  achieve  operational  interoperability  with  server- 
based  solutions  on  a  particular  intranet.  There  are  two  possible  approaches  for  a  working 
solution: 

1.  The  various  IETM  providers  must  put  their  own  physical  server(s)  plus  the  IETM 
View  Packages  on  the  user  intranet  (very  feasible  with  the  state-of-the-art  and 
capacity  of  today's  portable  computers  and  plug-in  network  standards);  or 

2.  All  IETM  creators  must  use  the  same  set  of  server  components  (i.e.,  the 
Application  Server)  and  install  the  standard  components  on  all  intranets  employed 
in  the  community  throughout  which  the  IETMs  are  interoperable. 

In  general,  option  2  is  only  feasible  for  a  tightly  controlled  community  and  not  applicable 
to  the  general  DoD  situation.  With  the  current  situation  described  above,  multi-unit  DoD 
forces,  such  as  would  be  involved  in  a  Joint  Operation,  would  have  to  rely  on  option  1  for 
interoperability  of  Application  Server  based  IETMs  (i.e.,  SI  or  S2).  The  JIA  is  intended, 
in  this  case,  to  be  a  facilitator  to  assure  that  this  “bring  your  IETM  preloaded  on  a  Web- 
Server”  approach  is  feasible  and  it  will  be  possible  to  achieve  interoperability  by  adding 
the  new  server  on  the  Joint  network,  a  feasible  practice. 
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6.2.2  Elements  Diagrams  for  the  Architecture  Types 

The  following  diagrams  more  fully  describe  the  differing  Architectural  Types  for  Object 
Encapsulation  (View-package  packaging  and  subsequent  installation  on  an  intranet). 

Figure  2  illustrates  the  requirement  of  a  client-based  Architecture  (Types  Cl  and  C2) 
with  two  kinds  of  software  elements:  Web  browsers  and  Web  servers.  In  general  these 
are  hosted  on  separate  devices  connected  by  a  TCP/IP  network  (i.e.,  LAN);  however,  an 
intranet  can  also  be  set  up  in  a  single  display  device  without  a  network.  In  the  case  of 
IETM  Architecture  Types  Cl  and  C2,  these  two  kinds  of  elements  are  all  that  is  needed. 

Figure  3  illustrates  the  requirement  of  Type  SI  for  an  additional  element,  the  Application 
Server,  sometimes  referred  to  as  a  Web-server  extension  because  it  effectively  operates  in 
the  same  operating  system  as,  and  is  an  extension  of,  the  HTTP  server. 

Figure  4  illustrates  the  requirement  of  Architecture  Type  S2  for  a  Database  Server  which 
hosts  most  of  the  IETM  content,  and  which  may  or  may  not  be  hosted  in  the  same  device 
as  the  Intranet  server.  A  Type  S2  application  usually  includes  aspects  of  a  Type  SI,  since 
it  requires  an  Application  Server  to  process  the  information-access  and  request  dialog 
between  the  Intranet  server  and  the  separate  Database  Server.  Note  that  while  the 
distinction  between  these  two  Types  may,  at  times,  not  be  clear,  they  differ  in  general  as 
to  where  the  primary  information  content  is  stored;  i.e.,  in  the  server  files  or  Database 
Management  System  (DBMS)  managed  databases. 
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Figure  2  -  Elements  for  Architecture  Types  Cl  and  C2 
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Figure  4  -  Elements  for  Architecture  Type  S2 
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6.2.3  General  Advisory  for  the  Deployment  of  the  Differing  Architectural  Types 

The  following  paragraphs  present  what  are  believed  by  the  author  to  be  helpful 
suggestions  for  deployment  of  the  various  Architectural  Types  of  IETMs.  They  are, 
however,  at  this  time  presented  as  optional  guidance  that  can  be  followed  if  the  IETM 
developer  or  program-office  customer  believer  they  apply  to  their  particular  situation. 

Where  appropriate,  the  Cl  Type  is  much  less  problem  prone  and  typically  yields  better 
performance  that  the  other  Types,  particularly  when  the  IETM  is  principally  preauthored 
and  contains  static  information  that  remains  the  same  from  one  presentation  to  the  next. 
Since  this  is  the  case  with  most  existing  printed  (legacy)  Technical  Manuals,  a  great  deal 
of  formerly  printed  TM  material  lends  itself  to  Type  Cl  presentation.  The  format  control 
needed  to  preserve  the  usability  and  contextual  content  of  paper  TMs  is  available  with 
HTML  4.0  with  Cascading  Style  Sheets  and  static  XML  coded  information.  The 
technology  is  very  good,  and  the  preparation  tools  are  inexpensive,  but  powerful,  for 
most  legacy-data  conversion  applications. 

The  high  end  of  the  spectrum,  the  Type  S2  application  with  a  DBMS  managing  the 
information  and  including  true  interactive  features  such  as  context  filtering  and  program 
sequences,  is  best  suited  to  large  weapon-system  IETMS.  An  additional  feature  of  all 
Server-based  systems  is  that  it  is  much  easier  to  manage  the  security  features  at  the 
Server  rather  that  manage  the  security  in  every  client  that  accesses  the  IETM  server.. 

Type  C2  applications  are  the  most  vulnerable  to  computer  virus  infection  in  that  they  may 
host  computer  viruses  and  bring  them  to  the  user  device  with  a  download.  Every 
downloaded  component  should  be  very  thoroughly  screened  upon  downloading,  often  a 
daunting  circumstance.  As  such,  it  is  the  advice  of  this  document  the  Type  C2 
implementation  should  be  limited  to  the  presentation  of  legacy  applications  where  it  is 
cost-prohibitive  to  do  other  than  this.  In  these  cases  it  is  typically  less  expensive  to  re¬ 
code  the  existing  application  as  a  plug-in  than  it  is  to  convert  over  to  a  new  authoring 
environment.  Emerging  DoD  security  concerns  over  downloadable  components  may 
render  the  employment  of  Type  C2  difficult  to  implement  in  a  DoD  system  that  must 
conform  to  the  new  information-assurance  and  operational- security  requirements. 
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Downloadable  software  components  are  a  major  concern  in  such  environments  to  the 
extent  that  they  may  be  banned  or  severely  restricted  by  cognizant  external  authority. 

A  possible  compromise  for  the  situation,  in  which  a  program  manager  deems  it  necessary 
to  have  a  custom  software  component  down-loaded  to  the  client  device,  is  to  provide  for 
an  software-component  install  page  which  is  separate  from  the  IETM.  This  install  page 
would  meet  the  automatic-install  requirement  for  JIA-compliant  downloadable 
components  but  would  entail  no  actual  IETM  data  display.  This  would  permit  the 
downloadable  software  component  to  be  placed  under  greater  security  scrutiny  at  the  time 
of  download  (e.g.,  Virus  scan,  digital  signature  check,  one  time  opening  of  software- 
install  permission  on  the  browser,  etc.).  Subsequent  to  that  process,  the  IETM  could  be 
employed  under  the  more  efficient  normal  use  mode  (i.e.,  without  all  the  security 
checking  in  place  but  with  no  permission  to  download  software  components). 

The  primary  reason  for  electing  a  Type  SI  solution  often  comes  as  a  result  of  the  business 
case  for  a  legacy-conversion  process.  An  application-server-based  Web  front  end  to  a 
legacy  application  is  often  the  least  expensive  method  of  Web-enabling  a  legacy 
application  of  any  sort.  However,  tt  times  the  size  of  the  Type  SI  file  base  may  be  a 
limitation  in  very  large  IETM  data  collections,  in  which  case,  the  IETM  would  be  better 
managed  using  an  established  Database  Management  Environment  intended  for  large 
data  stores  (i.e.,  Type  S2).  JIA  total  Object  Encapsulation  (i.e.,  encapsulating  the  total 
unmodified  legacy  application  with  a  Web  front  end)  is  primarily  intended  for  use  with 
existing  legacy  IETM  systems.  By  creating  a  single  interface  to  the  legacy  application, 
and  by  packaging  the  application  as  described  in  this  document,  a  legacy  IETM  may 
made  to  comply  with  the  JIA  standards. 

In  summary,  it  is  advised  that  either  type  Cl  or  S2  implementations  be  used  for  new 
IETMs.  C2  and  SI  implementations  should  be  limited  to  legacy  conversions  for  which  a 
substantial  economic  case  can  be  made. 
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Chapter  7.  Electronic-Addressing  and  Library  Functions 

7.1  Electronic  Addressing 

This  requirement  Chapter  is  the  most  technical  of  the  four  principal  requirement  areas, 
but  it  is  the  operational  key  to  usable  interoperability  between  two  of  more  IETMs. 

While  much  of  the  discussion  below  is  in  the  form  of  technical  jargon,  it  is  a  vocabulary 
widely  understood  among  developers  of  any  intranet  using  Web-based  protocols. 

7.1 .1  Requirements  applicable  to  IETM  developers 

Implementation  of  the  electronic  addressing  function  in  the  IETM  View  package  requires 
the  following: 

(1)  A  mechanism  and  format  (i.e.,  coding  format  and  associated  syntax)  for 
encoding  electronic  addresses  into  an  IETM  View  Package; 

(2)  A  defined  name  space  and  address  approach  (i.e.,  electronic  numbering 
system); 

(3)  Searchable  index  information  for  each  IETM  entry  point  that  conforms  to  an 
established  convention  so  that  a  intelligent  search  engine  can  locate  an  IETM 
reference  on  an  intranet  when  the  specific  locator  address  is  not  known. 

7.1 .2  Requirements  applicable  to  developers  of  IETM  infrastructure 
Execution  of  the  electronic  addressing  function  in  a  deployed  IETM  also  requires  the 
following: 

(1)  A  network  service  which  assigns  the  virtual  server  reference  in  the  IETM  to 
the  actual  server  IP  address  upon  which  the  target  IETM  resides. 

There  are  two  mechanisms  for  providing  this  service  in  a  particular  implementation.  The 
simplest  for  a  small  network  is  to  modify  the  “Hosts”  file  in  operating  system  of  every 
client  device  (this  file  exists  in  all  UNIX  and  Windows  environments)  to  contain  the 
required  virtual  server-to-network-IP-address  mappings.  The  other  is  to  employ  an 
additional  Domain  Name  Server  (DNS)  which  contains  the  needed  server-name-to-IP- 
address  mappings  (or  to  modify  the  principal  DNS  if  the  only  purpose  of  the  intranet  is 
the  use  of  IETMs).  Note,  this  minor  but  important  service  is  the  only  modification  of  an 
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existing  intranet  needed  in  order  to  put  IETMs  on  the  intranet.  Employing  the  “Hosts”- 
file  option  doesn’t  require  any  addition  to  the  infrastructure  but  does  require  that  all  the 
devices  that  might  read  the  IETMs  have  their  “Hosts”-file  modified  every  time  an  IETM 
is  added  to  the  intranet,  while  the  IETM  DNS  permits  configuration  management 
function  to  be  performed  one  time  at  one  site. 

7.1 .3  Core  Electronic  Addressing  Requirement 

The  syntax  for  JIA  electronic  addressing  will  be  based  on  the  existing  Universal 
Resource  Locator  (URL)  standard  for  the  World  Wide  Web,  because  it  is  widely 
implemented  in  virtually  all  Web-enabled  vendor  products.  For  such  an  implementation, 
an  occurrence  of  a  legitimate  URL  string  of  characters  is  automatically  made  "hot"  in  the 
vendor  application.  A  mouse  click  on  that  hot  spot  by  the  end-user  will  launch  a  Web- 
browser  information  request  from  the  intranet  on  which  the  browser  is  operating.  The 
browser,  in  turn,  will  locate  the  file  referenced  by  the  URL  and  display  it  on  the  screen. 

In  addition  to  requiring  a  standard  URL  syntax,  this  Electronic  Addressing  and  Library 
guidance  also  requires  that  each  of  the  Services  maintain  and  publish  a  permanent 
registry  of  all  valid  references  to  the  IETMs  issued  by  that  Service.  Once  published,  this 
pointer  to  such  a  valid  reference  should  not  be  changed,  though  the  logical  data  may  be 
updated.  If  deleted,  the  URL  data  request  should  return  a  “section  canceled”  (or  some 
appropriate  human  readable  message).  This  type  of  permanent  URL  is  called  a  persistent 
URL.  In  order  to  assure  that  URLs  are  indeed  persistent  URLs,  the  JIA  requires  the  use 
of  virtual  URLs  (vURLs),  as  described  below.  These  are  URLs  that  use  an 
administratively-assigned  syntactically-correct  server  reference  in  the  Internet  URL 
syntax;  however,  the  referenced  server  exists  in  name  only.  That  is,  a  server  by  that 
name  does  not  actually  exist  on  the  Internet  or  the  DII  and  the  name  is  used  for  data- 
management  purposes  only.  When  the  IETM  is  actually  installed  on  a  intranet  network, 
the  vURL  is  remapped  to  the  actual  server  on  which  the  IETM  data  resides  employing 
either  the  devices  “Hosts”  file  and/or  the  IETM-specific  Domain  Name  Services  (DNS) 
in  accordance  with  standard  World  Wide  Web  practices.) 
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The  specific  requirement  for  a  JIA-compliant  intranet  is  that  it  establish  the  capability  for 
the  remapping  of  these  vURLs,  which  reference  a  virtual  server,  into  the  actual  server  and 
file-system  locations  on  the  intranet  under  use. 

Guidance  for  establishment  and  use  of  vURLs  is  documented  in  Figure  5.  Initially  these 
DoD  addresses  will  probably  be  claimed  on  a  first-come-first-serve  basis,  to  be 
eventually  replaced  by  an  official  assignment  authority.  If  earlier  implementers  use 
reasonable  “ServerNames”  and  “LibraryNames”  (see  Figure  5)  unique  to  their 
community,  they  can  be  continued  in  the  official  registry  when  it  is  established. 

Figure  5  -  Guidance  for  Establishing  vURLs  in  the  JIA 


vURLs  will  be  authored  and  maintained  as  follows: 


HTTP  should  be  the  Web-page  protocol  to  be  utilized  in  this  Architecture  and 
construction  of  vURLs  will  use  standard  Internet  conventions  (i.e.,  the  URL  starts  with 
“HTTP://  and  is  followed  by  ServerName/LibraryName/FileDirectoryBreakdown  which 
may  be  terminated  by  a  moniker  [#,?]  followed  by  a  parameter  known  to  the  target). 
Format: 


http  ://ServerName/LibraryName/FileDirectoryBreakdown{  # 


or 


?]MonikerParameter 


ServerName  is  a  unique  name  applying  to  the  entire  set  of  IETMs  that  is  designed  to 
operate  from  the  same  server.  It  will  be  assigned  by  the  Service  IETM  registry.  The 
specific  rules  for  assigning  such  names  will  be  determined  by  the  Service  IETM 
registries. 

[The  assigned  Server  name  may  be  a  single  name  (e.g.,  ‘acbl23server’)  or  in  the  form  of 
‘natsf.navy.mil’  as  though  it  were  an  actual  server  on  the  Intranet.  If  an  Internet  notation 
is  employed,  it  is  possible  for  a  management  activity  to  actually  install  such  a  server  on 
the  Intranet.  They  could  maintain  all  of  their  cognizant  URL  references  on  that  site  in  the 
form  of  acknowledgment  as  valid  reference  even  if  the  actual  content  is  not  included  on 
that  site.  However,  the  use  of  single  names  (i.e.,  no  ‘dots’)  is  recommended  to  make  it 
much  clearer  that  a  IETM-peculiar  Domain  lookup  is  needed  when  the  IETM  is  mounted 
on  an  intranet.  Single  server  names  should  be  longer  than  3  characters  to  eliminate  the 
situation  of  being  confused  as  an  Internet  domain  such  as  ‘mil’  or  ‘org’.] 

The  LibraryName/FileDirectoryBreakdown  breakdown  notation  should  be  unique  across 
all  DoD  IETMs  and  should  be  administratively  assigned  as  though  it  were  the  IETM 
number  in  the  form  of  a  Unix  file-system  reference  with  forward  slashes  such  as 
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“/navyietmlibrary/fl8/ef/engine/ge/”  or  “/servicetmlibrary/tmnumber/systemnotation/. . 
The  allocation  of  this  “name  space”  will  be  managed  by  the  Service  IETM  Registries.  To 
permit  distributed  allocation  authority,  the  higher  (i.e.,  first)  index  field  would  be  unique 
to  the  individual-Service  registry. 

Additional  Directory  breakdown  of  files  within  the  IETM  reference  is  merely  a  further 
extension  of  the  assigned  FileDirectoryBreakdown  name  and  content  for  a  section  within 
an  IETM  and  may  be  null  for  the  top-level  reference. 

Sample:  “/navyietmlibrary/fl8/ef/engine/ge/diagnosis/test3”. 

Optional  specific-IETM-defined  monikers  may  be  utilized.  These  are  most  commonly 
used  for  carrying  a  bookmark  reference  of  a  detailed  database  access  parameters  in  the 
URL.  These  are  indicated  by  a  “#’  or  ‘?’  at  the  end  of  the  URL  followed  by  a  string  of 
information  which  is  processed  by  the  IETM  (and  not  the  Web  Server). 


Thus,  the  JIA  will  require  only  that  an  Electronic-Addressing  system  exists  and  that  it  use 
the  URL  syntax.  The  administrative  task  of  establishing,  assigning,  and  enforcing  the 
administration  of  the  address  space  for  IETMs  will  be  the  responsibility  of  some  standing 
management  activity  which  will  manage  an  IETM  Registry  for  each  Service. 

7.2  The  Library  Functions 

This  Electronic-Addressing  requirement  also  includes  a  requirement  for  an  on-line 
search- oriented  Library  that  is  implemented  by  the  inclusion  of  standard  ASCII-encoded 
tagged  metadata  package  to  support  on-line  searches.  This  metadata  package  will  be 
encoded  in  the  HTML  or  XML  index  page  and  tagged  as  ‘metadata’ .  This  index  page 
should  be  attached  to  each  IETM  View  Package  at  the  View  Package  root.  This  metadata 
is  a  set  of  searchable  keywords  and  other  identifying  information  in  a  standard  format 
that  is  associated  with  each  IETM  and  can  be  used  by  a  search  engine  to  identify  sought 
references. 

Establishing  the  area-library  or  searchable-access  mechanism  is  an  area  in  which  the  most 
difficult  task  will  not  be  technical.  The  challenge  for  an  administrative  activity  will  be  in 
securing  DoD-wide  agreement  for  adopting  a  standard  format  for  the  searchable 
metadata.  A  JIA  implementation  can  operate  without  metadata  by  relying  on  hard-coded 
URLs  for  linking  the  Intranet  and  IETM  information  together.  However,  the  real-world 
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experience  of  the  World  Wide  Web  has  shown  that,  in  practice,  users  rely  extensively  on 
search  engines  to  locate  reference  information  any  need  for  which  was  unforeseen  by  the 
content  authors.  Two  basic  approaches  exist  for  developing  a  searchable  data  base  of 
such  metadata:  one  is  to  create  it  after  the  fact  by  utilizing  a  semi-automated  third-party 
indexing  service  or  mechanism  (the  approach  commonly  used  on  the  World  Wide  Web); 
the  other  is  to  require  the  content  providers  to  author,  in  a  structured  format,  a  searchable 
information  data  set.  The  method  preferred  by  the  JIA  is  to  employ  an  ASCII-encoded 
HTML/XML  data  set  with  each  searchable  index  being  indicated  by  a  set  of  user-defined 
XML  tags  in  the  context  of  a  “metadata”  tag. 

In  summary,  every  IETM  View  Package  should  contain  a  referencable  default  root  file  in 
its  top  directory  (by  intranet  de  facto  standard  named  “default.htm”  or  “default. html”) 
which  actually  kicks  off  the  IETM  (it  can  automatically  link  to  the  actual  start  point  for 
the  IETM  if  a  different  start  point  is  required)  and  an  index  file  named  “index.htm”  or 
“index. html”  in  the  same  root  directory  and  which  contains  the  required  metadata. 

Chapter  8.  Server  and  Data-Base  Interface 

The  simplest  way  for  the  JIA  to  achieve  IETM  interoperability  across  the  DoD  is  to 
utilize  only  generic  Web-type  servers.  Such  an  approach  will  not  require  that  additional 
software  be  overtly  installed  on  either  the  servers  or  the  browser  device.  However,  many 
legacy  systems  and  some  highly  innovative  new  IETM  applications  require  some  sort  of 
custom  server  extensions  beyond  those  of  the  standard  Web-type  server  and,  most  likely, 
database  interface  components.  For  these  complex  IETMs,  which  require  extended 
services  operating  on  an  intranet  server,  the  installation  of  the  IETM  on  the  Server  will 
involve  two  processes.  One  process  will  be  to  extend  the  intranet  Web-type  server  by 
installing  extended  services.  The  other  process  will  be  to  install  the  IETM  information 
and  any  included  downloadable  browser  software.  Some  of  the  general  guidance  relating 
to  many  of  these  JIA  support  issues  needed  to  support  these  additional  services  is 
discussed  below. 

The  server  capabilities  needed  are  highly  dependent  on  the  type  of  the  Architecture  being 
utilized  by  a  particular  implementation.  For  Types  Cl  and  C2,  virtually  any  commercial 
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HTTP  server  can  be  employed.  In  these  cases,  only  the  Object-Encapsulation  and 
Software-Component  Interface  requirement  discussed  earlier  in  this  guidance  document 
is  needed  to  outline  the  requirement  to  IETM  suppliers  for  the  packaging  of  their  IETM 
View  Packages.  This  ease  of  installing  the  Type  C  IETMs  onto  a  Web-type-server  makes 
them  the  preferred  type  for  the  support  of  Joint  Operations  when  an  ad-hoc  electronic 
library  needs  to  be  quickly  assembled. 

In  the  case  of  Type  S  implementations,  the  developer  of  the  IETM  will  need  to  provide 
software  and  data  components  and  the  detailed  instructions  on  how  to  install  them  as  one 
or  more  additional  servers,  i.e.,  the  Application  Servers  and/or  the  Database  Servers 
needed  for  Type  S  IETM  applications.  The  concept  of  auto-install  that  is  embodied  in 
the  JIA  for  the  browser  components,  in  general,  will  not  apply  to  the  administration  of 
these  back-end  servers.  While  it  is  the  goal  of  the  JIA  that  browser  devices  will  require 
no  system  administration,  the  JIA  servers  will  still  require  an  administrator  for  the 
installation  of  server  software  components.  In  the  case  of  a  Type  S  Architecture,  the 
provider  of  the  IETM  will  have  to  arrange  separately  for  the  installation  of  server 
components  on  the  target  intranet.  The  intent  of  the  guidance  in  this  document  is  to 
assure  that  this  one-time  installation  is  fully  documented  by  the  IETM  supplier  and  is  as 
simple  and  automated  as  possible,  so  that  field-system  administrators  can  easily  add  it  to 
an  existing  server  site. 

Provision  of  definitive  guidance  in  the  JIA  regarding  these  add-on  servers  is  complicated 
by  the  fact  that  new  technology  is  continually  emerging  and  evolving  in  the  server 
marketplace  today.  There  is  economic  pressure  on  software  vendors  to  develop  a 
competitive  advantage  (i.e.,  proprietary  non-standard  features)  in  their  server  products, 
since  it  is  widely  recognized  that  profits  will  be  made  only  in  the  server  marketplace,  as 
opposed  to  the  browser  marketplace.  Vendors  will  seek  to  make  their  profit  in  the 
Server  market,  and  a  direct  result  will  be  a  proliferation  of  proprietary  server  products,  a 
situation  that  will  continue  to  complicate  the  standardization  of  DoD  servers.  Unless  the 
DoD  chooses  to  go  back  to  demanding  full  MILSPEC  software,  there  is  little  the  DoD 
can  do  to  change  the  marketplace  for  these  products. 
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Specific  considerations  for  developing  both  Application  and  Database  Server  capability 
in  a  JIA-compliant  intranet  are  summarized  below. 

8.1  Type  SI  Server  Support 

Type  SI  applications  require  software  extensions  beyond  the  simple  HTTP  or  Web-type 
server.  The  most  common  approach  is  to  use  an  entirely  proprietary  Web+application 
server  which,  when  installed,  automatically  provides  all  specific  custom-application 
software.  These  proprietary  products  offer  powerful  functionality  because  of  the  custom 
server  software,  but  create  a  software-maintenance  requirement  for  the  life  of  the  product. 
The  server  software  must  typically  be  modified  to  upgrade  the  functionality  of  the  IETM. 
The  general  guidance  is  that  such  applications  of  S 1  IETMs  should  be  limited  to  either  of 
two  basic  classes  of  IETMs:  (1)  a  wholesale  move  of  a  stand-alone  legacy  application  to 
a  Web  based  approach,  or  (2)  a  situation  in  which  the  primary  purpose  of  the  server  is  to 
provide  these  custom  services  and  the  intelligence  of  the  server  is  the  purpose  of  the 
IETM. 

8.2  Type  S2  Server  Support  (Database  Interface) 

Type  S2  Architecture  applications  are  a  particularization  of  the  general  Type  S 
application.  They  involve  server  applications  in  which  the  IETM  content  is  primarily 
resident  in  a  DBMS-managed  database,  and  the  Object  Encapsulation  in  the  file-based 
Web  pages  serves  as  organizing  shells  or  templates.  In  fact,  in  an  IETM  for  which  the 
format  has  stabilized,  there  may  be  no  need  to  modify  the  portions  of  the  Encapsulated 
Objects  managed  by  the  Web-type  and  Application  servers  when  content  changes  are 
made.  Only  the  database  instance  needs  to  be  modified.  Virtually  all  database  vendors 
are  marketing  a  Web-enabled  variant  of  their  DBMS.  This  is  an  emerging  area  in  which 
new  products  are  being  developed  and  made  available  to  the  COTS  marketplace  on  a 
continuing  basis.  Many  of  these  are  applicable  to  IETMs.  It  is  neither  possible  nor 
desirable  to  restrict  or  standardize  the  Type  S2  solutions  at  this  time,  as  affordable  COTS 
technology  is  just  now  emerging  in  the  marketplace. 

It  will  be  necessary  that  Type  S  applications  for  DoD  IETMs  support  the  “occasionally 
connected”  scenario,  in  which  a  PEDD  is  to  be  downloaded  with  an  IETM  and  then 
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detached  from  the  intranet  in  order  for  the  technician  to  perform  work  at  the  maintenance 
site.  This  procedure  requires  that  a  local  copy  of  the  Application  and/or  Database  Servers 
be  installed  on  the  portable  display  device  and  that  some  facility  be  established  to  keep 
the  local  copy  of  the  database  synchronized  with  the  main  database  on  the  intranet. 

IETM  developers  must  be  sure  that  this  requirement  is  properly  addressed  when 
developing  a  S2  IETM  application.  As  is  typically  the  situation  with  these  Type  S 
applications,  the  available  solutions  to  support  the  mobile  user,  while  powerful,  are 
proprietary  and  not  amenable  to  standardization.  Despite  this  lack  of  standardization, 
these  COTS  products  can  be  deployed  on  a  JIA  intranet,  largely  a  byproduct  of  being 
developed  for  commercial  application  on  the  World  Wide  Web  which  requires  such 
interoperability. 

8.3  Updating  DBMS-Managed  Information  on  a  Server 

The  Type  S2  Architecture  application  is  the  most  likely  mature  architecture  for  traditional 
Class  4  IETMs  (i.e.,  those  based  on  MIL-PRF-87269^];  however,  the  technology  and  the 
collection  of  product  to  support  these  Web-oriented  database  applications  is  currently 
very  immature,  and  definitive  products  are  still  emerging  in  the  marketplace.  An  area 
particularly  needing  continuing  assessment  regarding  its  role  in  the  JIA  is  the  updating 
and  synchronization  of  databases  in  the  field.  In  practice,  the  least  risky  way  to  update 
such  databases  is  to  use  the  tools  applicable  to  the  particular  Data  Base  Management 
System  (DBMS)  being  utilized.  Most  DBMS  vendors  have  very  good  but  proprietary 
data-replication  facilities  for  this  very  purpose.  The  JIA  concept  of  best  commercial 
practices  would  dictate  that  such  capability  be  utilized  as  long  as  it  operates  over  a 
TCP/IP  network  (i.e.,  an  intranet). 

Chapter  9.  Maintaining  a  Common  Look-and-Feel  among  Differing 
IETMs 

While  the  use  of  the  common  browser  does  standardize  many  of  the  user-interaction 
features,  it  is  very  likely  that  a  custom  component  will  contains  its  own  set  of  unique 

8  Military  Specification,  MIL-PRF-87269  Data  Base,  Revisable:  Interactive  Electronic  Technical 
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user-interaction  features  layered  under  the  higher-level  browser  toolbars.  These  features 
often  conform  to  a  proprietary  look-and-feel  dictated  by  the  COTS  product  being 
employed.  However,  a  requirement  still  exists  for  a  procurement-guidance  document 
which  can  be  employed  to  minimizing  the  differences  in  look-and-feel  among  various 
disparate  IETM  presentation  components  that  operate  in  the  JIA  environment.  From  both 
the  Training  and  the  Job  Performance  perspective,  the  effectiveness  of  each  product  is 
enhanced  when  it  is  displayed  in  accordance  with  a  standard  style,  even  if  the  actual 
underlying  IETM  presentation  components  vary  and  are  proprietary  in  nature. 

9.1  Joint  DoD/Industry  Effort  to  Develop  a  User  Interaction  Guideline 

A  preliminary  set  of  standard  proposed  “Look-and-Feel”  Recommendations  is  included 
in  this  guidance  document  and  listed  below.  It  represents  a  meaningful  attempt  to 
prepare  guidance  for  the  suppliers  of  IETMs  and  IETM  software  products  associated  with 
the  Aerospace  Industries  Association  (AIA).  These  guidelines  permit  the  use  of 
contractor  selected  authoring  and  presentation  products  while,  at  the  same  time, 
preserving  the  essence  of  a  common  DoD  Look  and  Feel  if  the  software  products  adhere 
to  the  guidelines.  This  proposal  is  the  result  of  a  Joint  workshop  between  members  of  the 
individual  Services  (selected  by  the  Tri-Service  IETM  Technology  Working  Group 
members)  and  the  AIA  Service  Publications  Panel.  The  AIA  members  are  experienced 
practitioners  in  IETM  development  and  have  a  broad  knowledge  of  the  practical  side  of 
adapting  commercial  products  without  calling  for  expensive  custom  modifications.  The 
recommendations  contained  below  are,  however,  intended  to  apply  to  all  DoD  IETM 
applications  and  not  just  to  Aerospace  systems.  The  approach  used  in  this  report  greatly 
reduces  the  existing  performance  requirements  to  those  few  that  are  really  needed,  and 
tightens  down  those  few  remaining  requirements  to  be  as  specific  as  possible.  While  not 
an  official  position  at  this  point  in  time,  the  consensus  of  the  group  that  developed  these 
guidelines  was  that  these  would  eventually  replace  the  user-interaction  requirements 
sections  of  MIL-PRF-87268^  the  IETM  specification. 


Manuals,  For  the  Support  of 

9  Military  Specification,  MIL-PRF-87268  Manuals,  Interactive  Electronic  Technical:  General  Content, 
Style,  Format,  and  User-Interaction 
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IETM  TMCRs  (Technical  Manual  Contract  Requirements)  and  other  procurement 
instruments  can  require  that  delivered  IETM  View  Packages  conform  to  both  the  JIA 
performance  requirements  and  the  included  Look-and-Feel  user-interface  requirements. 
By  doing  so,  it  will  be  possible  to  obtain  a  meaningful  level  of  common  DoD  IETM  look- 
and-feel  interface  without  requiring  the  acquisition  of  a  custom  IETM  system.  It  is 
expected  that  either  the  AIA  or  the  Tri-Service  IETM  Technology  Working  Group  (or 
both)  will  publish  this  document  in  the  near  future  so  it  can  be  cited  in  functionally 
specified  IETM  procurement  documents. 


9.2  Preliminary  Draft  of  User-Interaction  Requirements  for  DoD  lETMs 

The  following  is  a  Preliminary  Draft  of  IETM  User-Interaction  (“Look-and-Feel”) 
Guidelines  developed  by  the  Service  Publication  Panel  of  the  Aerospace  Industries 
Association  and  the  Tri-Service  IETM  Technology  Working  Group  at  a  AIA  and  Tri- 
Service  IETMTWG  Workshop  15-18  March  1999  at  Naval  Surface  Warfare  Center, 
Carderock,  Maryland. 


User-Interaction  Requirements  for  DoD  IETMs 

The  following  guidelines  should  be  observed  in  preparing  IETMs  and  the  associated 
viewing  software  components  for  the  Department  of  Defense: 

9.2.1  Display  Format  (Text/font,  graphic,  table,  lists.  Object  Embedding) 

-Use  Best  Commercial  Practices 

-Use  of  multiple  frames  (formerly  “panes”)  is  not  a  requirement 

9.2.2  Browse  Capability 
-Browse  capability  should  be  available 

-User  controlled  access  mode 
-No  tracking  of  activities 
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-Not  rigidly  tied  to  IETM  controls 

9.2.3  Link  Behavior/Navigation 

-Persistent  visual  indication  of  link(s)  to  additional  information  should  be  available. 

-There  should  be  a  visual  indication  of  how  the  link  behaves  (e.g.,  goto,  gosub,  relational) 

-If  you  are  executing  a  link  that  is  not  a  goto  or  exit  link,  you  should  be  able  to  return  at  anytime 
to  where  the  link  began. 

9.2.4  Control  Bars 

-The  User  Navigation  Panel  (Tool  Bar)  should  provide  the  necessary  choices/options  available  at 
the  current  time. 

-The  User  Navigation  Panel  is  required  with  an  optional  toggle  capability  to  turn  it  off. 

-The  User  Navigation  Panel  should  remain  accessible  by  persistent  visible  indication. 

-Use  the  standard  icons  when  applicable  in  the  User  Navigation  Panel. 

9.2.5  Icon  Standardization 

-An  icon  should  show  its  name  or  function  when  the  cursor  is  stalled  over  the  icon. 

-Suggested  Icons  for  standardization: 

+Next 

-(-Previous  [Chronological] 

+Return  [Chronological] 

-i-Back  [Logical] 

+TOC 

+Exit 

+Find/Search 

+Undo 

+User  Navigation  Panel  Minimized 
-(-Processing  Indication 
-(-Parts  (IPB/RPSTL) 

+Suggested  Changes/Feedback 
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+Training 

-(-Multimedia  Icon 

+Sound/Voice  Icon 

+Full  Motion  Video  Icon 

+Animation  Icon 

-(-Graphic 

-(-Diagnostics 

+ Warning 

-(-Caution 

+Note 

-(-Hazards  per  AIA  PUB  1 19  /  Icons  included  in  MIL-STD-38784 
-(-Print 

+One  way  link  (Goto) 

-(-Two  way  link  (Gosub) 

-(-Relational  link 
-(-Browse 

9.2.6  Selectable  Elements  ( Hot-Spots ) 

-All  Hot  Spots  must  be  visually  indicated  (e.g.  fill  pattern,  reverse  video,  outline,  button, 
underline...) 

-There  are  three  acceptable  modes  of  visual  indication  of  hot-spots  (selectable  areas). 

-Persistent  visual  indication  that  an  area  is  hot 
-Cursor  changing  shape/color 

-Object  changes  while  cursor  over  area  (e.g.  IPB  callout  expands. . .) 

-There  should  be  an  indication  of  link  destination  (target)  when  the  cursor  passes  over  the  hot¬ 
spot 

9.2.7  Warnings,  Cautions,  Notes 

-User  must  acknowledge  pop  up  warnings  and  cautions  before  proceeding. 

-Pop  up  alerts  should  be  centered  on  the  screen 

-A  persistent  icon  should  appear  on  the  screen  when  alert  is  applicable. 
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-Alerts  should  appear  in  standard  colors:  Red  -  Warning,  Yellow  -  Caution,  Cyan  -  Note 

9.2.8  Search  &  Lookup 

-Use  the  standard  icon  to  get  the  user  into  a  search  mode. 

-The  user  should  be  presented  with  the  search  options  available. 

-At  a  minimum,  a  Keyword  search  against  valid  entry  points  (TOC/List  of  Content)  should  be 
available 

-The  system  should  provide  a  search  capability  against  Metadata  (e.g.  Keywords,  tagged  data, 
indexable  data,  searchable  data,  etc.)  when  it  exists. 

9.2.9  Session  Control  ( Suspend ,  Resume,  Nested  Sessions) 

-The  user  should  be  able  to  suspend  a  session  at  any  time,  (e.g..  Break,  Emergency,  No  Parts) 

-A  subsequent  resume  should  be  capable  of  re-starting  the  session  at  the  same  point  it  was 
suspended. 

-At  the  time  of  resume,  the  user  should  be  advised  that  some  key  parameters/condition  settings 
may  be  out-of-date  (e.g.  aircraft  safe  for  maintenance,  temperature  change,  or  other  people 
worked  on  the  end-item/platform  during  the  suspension) 

-The  system  should  support  the  three  Exit  Modes: 

-Complete  (Save  and  update  history) 

-Abort  (Don’t  save  or  update  history) 

-Suspend  (See  above) 

9.2.10  Context  Filtering 

-The  system  should  have  the  ability  to  perform  context  filtering  on  effectivity  as  a  minimum. 

-The  system  should  provide  the  user  a  mechanism  for  entering/modifying  configuration 
parameters. 

9.2.1 1  Screen  Resolution  and  Color  Guidelines 

-Presentation  system  and  graphics  developers  should  consider  the  use  of  standard  “safe”  colors 
visible  across  multiple  presentation  systems. 

-Presentation  systems  should  not  presume  any  fixed  display  resolution,  or  size. 
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9.2.12  Information  Access  ( Indices ,  Electronic  TOC’s,  etc.) 

-A  Table/List  of  all  key  entry  points  should  be  made  available  for  user  access. 

-Access  should  be  provided  via  a  Hierarchical  Breakdown  such  as: 

-SSSN  (MIL-STD-1808) 

-LCN 

-AECMA  1000D 

-Functional  and  Physical  Hierarchy 
-Graphical  Interfaces  are  acceptable. 

9.2.13  Dialogs 

-Support  should  be  provided  for  both  pop-up  dialog  box  and  in-line  dialogs  in  the  display  frame 
itself. 

-Developers  should  use  Best  Commercial  Practices  for  entering  data  in  dialog  boxes  (e.g.  radio 
buttons,  check-boxes,  fill-ins,  combo  boxes,  scrolling  selection  lists,  etc.) 

9.2.14  Sound 

-Developers  should  use  Best  Commercial  Practices  when  implementing  sound. 

-The  user  must  take  action  to  hear  the  sound.  (No  automatic  playing  of  sound.) 

-User  controls  muting  and  volume  via  system  controls  (versus  embedded  controls  within  the 
application).  Optional:  Application  can  provide  convenient  access  to  the  system  controls. 

9.2.15  Voice  I/O 

-Voice  PO  should  be  used  only  as  supplemental  input/output  and  navigation.  Keyboard  and 
pointing  devices  should  be  the  primary  input,  and  visual  display  should  be  the  primary  output. 

9.2.16  Graphics 

-Developers  should  use  Best  Commercial  Practices  for  graphics  format  and  display. 

-Preferred  Vector  Graphics  Std:  CGM  -  WebCGM  Type  4  Profile  (moving  towards  ISO  Std) 

9.2.17  Hardware  User  Interface:  Point  and  Click,  Voice,  Selection  Keys,  A/N 

Keyboard,  Touch  Pad,  etc. 

-Point  and  click  capability  on  target  display  should  be  assumed. 
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-Developers  should  accommodate  the  limitations  of  the  target  display  device. 

-Alphanumeric  Input  Capability  must  be  provided,  if  not  in  hardware,  then  in  software. 

9.2.18  Performance  ( Response  Time  by  Context) 

-Developers  should  implement  a  2  second  response  time  goal. 

-If  the  response  time  is  greater  than  2  seconds,  the  system  should  provide  visual  feedback  to  the 
user. 

-  Use  a  standard  cursor  for  Processing  Indication. 

9.2.19  Printer  Output 

-Printer  Output  is  strongly  discouraged. 

-Print  capability  should  be  used  primarily  for  graphics. 

-All  printer  output  should  have  version  number  and/or  printed  date/time  stamp 
-When  customer  requires  printed  output: 

-Printer  output  should  not  have  to  conform  to  normal  Paper  TM  Specifications 
-Satisfactory  Options: 

-“pre-composed”  files  (such  as  Adobe  PDF)  can  be  attached 

-“on-the-fly”  composition  for  printing  (of  logical  element)  built  into  the  viewing 
application 

-Screen  Print.  Preferred  method:  print  data  content  of  Active  Window  only. 

9.2.20  User  Annotations  (e.g.,  comments,  user  notes,  redlines,  bookmarks ) 

-There  should  be  a  persistent  visual  indication  that  an  annotation  exists. 

The  default  initial  presentation  of  annotations  is  to  appear  minimized. 

-If  there  are  levels  of  annotations  (e.g.,  Public,  Private,  etc.),  they  should  be  visually 
differentiated. 

9.2.21  Feedback  to  Originator  (e.g.,  TMDRS,  Form-2028,  AFTO  22) 

-A  single  user  interaction  should  be  available  to  select  the  function,  (e.g.,  a  Button,  double  mouse 
click) 
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-The  preferred  user  interface  is  a  form. 

-The  system  should  provide  an  output  compatible  with  the  user  environment. 

-There  should  be  a  “Form  fill-in  completed”  function  before  returning  to  the  IETM  (e.g  . 
“submit”,  “done”,  “okay”,  “close-out”.) 

-  The  system  should  automatically  generate  an  Electronic  locator  (e.g.,  Address,  Version,  ...)  and 
to  the  greatest  extent  possible,  relevant  fields  on  the  Form  should  be  automatically  filled-in. 

(e.g.  User  Id,  System  State,  etc.) 

9.2.22  Administrative  Information  (e.g.  Effectivity,  Authorization,  Distribution, 

Val/Ver) 

-Administrative  information  should  be  displayable. 

9.2.23  Interface  to  External  Systems 

-A  single  user  interaction  should  electronically  link  to  external  references  (e.g.  another  IETM)  or 
external  systems  (e.g.  CAMS,  IMDS,  FEDLOG,  GCSS,  Supply  Support/Parts  Ordering,  etc.). 

9.2.24  Rapid  Action  Changes  (IRAC)/ Critical  Safety  Interim  Messages 

-A  visual  indication  of  the  existence  of  a  critical  change  must  be  displayed  in  context. 

-A  single  user  interaction  should  be  available  to  access  the  change. 

-The  user  should  be  provided  with  a  visual  indication  for  critical  messages  at  the  start  of  the 
IETM. 

9.2.25  Major  Data  Types  (e.g.  Troubleshooting,  Procedural,  Parts,  Descriptive, 

etc....) 

-Because  of  differences  in  user  cultures  and  requirements  this  area  cannot  be  addressed  by 
providing  guidance.  Lessons  learned  may  be  a  better  way  to  address  this  category 
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Chapter  1 0.  Definitions  and  ACRONYMS  used  in  this  report. 

10.1  Definitions 

browser  A  client  program  which  runs  on  a  user’s  computer  and  which,  by  means  of 

hypertext  links,  enables  retrieval  and  display  of  information  available  on  the  World  Wide 

Web  or,  as  used  in  this  Report,  on  an  intranet. 

Communications  Security  (COMSEC)  Involves  all  measures  taken  to  safeguard  the 
handling  of  information  on  an  information  system.  It  includes  [1]  emanations 
security  (EMSEC);  [2]  electronics  security  (i.e.,  prevention  of  interception  of  non¬ 
communication  electromagnetic  radiation  which  can  provide  system  information; 

[3]  transmission  security  (TRANSEC);  and  [4]  cryptographic  security. 

Information  Assurance  Defensive  Information  Operation  measures,  including: 

[1]  protection  of  the  information  infrastructure  by  prevention  of  unauthorized  access 
or  attack,  and  [2]  defense  of  the  information  infrastructure  by  detecting,  surviving, 
and  responding  to  attacks.  Information  assurance  has  the  following  properties  and 
capabilities: 

(1)  Availability  of  the  information  to  the  user  when  needed. 

(2)  Integrity;  freedom  from  unauthorized  tampering. 

(3)  Authentication;  existence  of  controls  to  provide  assurance  that  only  authorized 

users  have  access  to  the  information. 

(4)  Confidentiality;  protection  from  accidental  release. 

(5)  Non-repudiation;  protection  from  false  denial;  capability  of  verification. 

(6)  Restoration;  assurance  that  information  and  infrastructure  can  survive  an  attack, 

and  that  the  system  can  resume  operation  after  the  attack. 

Internet  A  system  of  linked  computer  networks,  international  in  scope,  that  facilitates 
data  communication  services  such  as  remote  log-in,  file  transfer,  electronic  mail, 
and  newsgroups.  The  Internet  is  a  way  of  connecting  existing  computer  networks 
that  greatly  extends  the  reach  of  each  participating  system.  It  was  originally 
developed  in  the  1970s  by  the  DoD  on  the  ARPAnet.  In  common  usage,  the 
terms  Internet  and  World  Wide  Web  are  often  used  interchangeably,  however, 
there  are  applications  and  protocols  operating  on  the  Internet  that  are  not  part  of 
the  World  Wide  Web.  The  term  “internet”,  written  with  lower-case  “i”,  is  often 
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used  to  refer  to  a  WAN,  or  a  group  of  LANs  connected  by  means  of  a 
communications  protocol. 

intranet  A  dedicated  communications  network  of  one  or  more  LANs  utilizing  the 
protocols  of  the  Internet.  As  used  in  this  Report,  the  term  “intranet”  designates  an 
entirely  self-contained  system  with  controlled  access  and  centralized  management 
through  an  assigned  infrastructure. 

LAN  (Local  Area  Network)  A  network  contained  within  a  single  physical  site  or 
activity  (one  or  more  buildings),  as  contrasted  with  a  WAN. 

URL  (Uniform  Resource  Locator)  An  alphanumeric  string  that  describes  the  location 
and  access  method  of  a  resource  on  the  Internet;  for  example,  the  URL 
http://www..  .  .  describes  the  type  of  access  method  being  used  (http)  and  the 
server  location  which  hosts  the  Web  site. 

WAN  (Wide  Area  Network)  A  communications  network  of  several  physically  or 
organizationally  separate  locations,  as  opposed  to  a  LAN.  The  Internet  is  an 
example  of  a  world-wide  WAN.  Workstations  and  computers  within  a  given 
activity  are  generally  connected  to  each  other  with  a  LAN,  by  means  of  wires  or 
radio  waves. 


World  Wide  Web  (“WWW”  or  “the  Web”)  A  global  network  of  servers  on  the 
Internet  hat  provide  access  to  hypertext-linked  (http)  databases  and  files 
(documents,  usually  written  in  HTML)  by  means  of  a  browser.  It  was  developed 
in  1989,  and  is  now  the  primary  platform  of  the  Internet.  Web  pages  store 
retrievable  hypermedia  information  (graphics,  sound,  animation,  video)  in 
addition  to  text. 


10.2  ACRONYMS  Used  in  This  Document 

DUSD(L)/LRO  -  Logistics  Reinvention  Office  of  the  Office  of  the  Deputy 
Undersecretary  of  Defense  for  Logistics 


ETM  -  Electronic  Technical  Manuals 


FTP  -  Internet  File  Transfer  Protocol 


GCSS  -  Global  Combat  Support  System 
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GIF  -  Graphics  Interchange  Format 
HTML  -  HyperText  Markup  Language 
HTTP  -  Hypertext  Transfer  Protocol 

IETM  -  Interactive  Electronic  Technical  Manual 

IETMTWG  -  Tri-Service  IETM  Technology  Working  Group 
IPSDB  -  Integrated  Product  Support  Database 

JCG-CE  -  Joint  [Logistics]  Commanders  Group  for  Communication  and  Electronics 

JECPO  -  Joint  Electronic  Commerce  Project  Office 

JIA  -  Joint  IETM  Architecture 

JPEG  -  Joint  Photographic  Experts  Group 

JTA  -  DoD  Joint  Technical  Architecture 

LAN  -  Local  Area  Network 

NIA  -  Navy  IETM  Architecture 

PDF  -  Portable  Document  Format 

PEDD  -  Portable  Electronic  Display  Device 
PKI  -  Public  Key  Infrastructure  (PKI) 

TCP/IP  -  Telecommunications  Protocol/Internet  Protocol 
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TIFF  -  Tagged  Image  File  Format 

TMCR  -  Technical  Manual  Contract  Requirements 

URL  -  Uniform  Resource  Locator 

VP  -  View  Package  -  the  name  given  to  the  encapsulated  object  of  the  IETM 

VURL  -  virtual  URL 
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